Logs for jdev

Show join/part/nick changes:

[05:47:08] * johnny left the chat.
[05:47:13] * johnny joined the chat.
[05:49:09] * johnny left the chat.
[05:49:14] * johnny joined the chat.
[05:55:24] * Tobias joined the chat.
[06:11:03] * ermine joined the chat.
[06:11:56] * Lance Stout left the chat.
[06:13:41] * jprieur joined the chat.
[06:13:51] * jprieur left the chat.
[06:14:44] * smoku left the chat.
[06:21:48] * jprieur joined the chat.
[06:21:50] * jprieur left the chat.
[06:22:59] * Neustradamus left the chat.
[06:28:24] * mlundblad_laptop joined the chat.
[06:28:28] * mlundblad_laptop left the chat.
[06:28:38] * mlundblad_laptop joined the chat.
[06:28:59] * mlundblad_laptop left the chat.
[06:29:00] * mlundblad_laptop joined the chat.
[06:29:29] * mlundblad_laptop left the chat.
[06:29:39] * mlundblad_laptop joined the chat.
[06:37:35] * Guus joined the chat.
[07:10:00] * Guus left the chat.
[07:13:26] * Guus joined the chat.
[07:14:30] * Guus left the chat.
[07:15:14] * Guus joined the chat.
[07:23:19] * alfeberlin joined the chat.
[07:23:54] * alfeberlin left the chat.
[07:39:02] * Alex joined the chat.
[07:42:30] * nabatt joined the chat.
[07:45:03] * scippio left the chat.
[08:16:43] * petermount joined the chat.
[08:59:11] * luca tagliaferri joined the chat.
[09:04:13] * smoku joined the chat.
[09:13:14] * jprieur joined the chat.
[09:17:22] * jprieur left the chat.
[10:09:37] * smoku left the chat.
[10:09:38] * smoku joined the chat.
[10:25:03] * waqas left the chat.
[10:28:22] * Neustradamus joined the chat.
[10:34:27] * waqas joined the chat.
[10:50:23] * jcea joined the chat.
[10:53:34] * smoku left the chat.
[10:53:36] * smoku joined the chat.
[10:56:47] * jugg joined the chat.
[11:01:27] * smoku left the chat.
[11:01:28] * smoku joined the chat.
[11:31:39] * jonas joined the chat.
[11:36:03] * jcea left the chat.
[11:36:59] * Lance Stout joined the chat.
[11:38:55] * smoku left the chat.
[11:55:54] * Florob joined the chat.
[12:03:51] * alfeberlin joined the chat.
[12:15:54] * Zash joined the chat.
[12:19:03] * Lance Stout left the chat.
[12:30:52] * Lance Stout joined the chat.
[12:37:46] * jcea joined the chat.
[12:42:01] * petermount left the chat.
[12:46:01] * smoku joined the chat.
[12:49:25] * alfeberlin left the chat.
[12:52:57] * Lance Stout left the chat.
[12:57:14] * petermount joined the chat.
[13:01:38] * Lance Stout joined the chat.
[13:14:46] * deryni joined the chat.
[13:20:36] * Tobias left the chat.
[13:47:51] * zanchin joined the chat.
[13:49:20] * nabatt left the chat.
[13:56:40] * Zash left the chat.
[13:56:55] * Zash joined the chat.
[14:01:02] * jugg left the chat.
[14:01:06] * Guus left the chat.
[14:10:56] * Alex left the chat.
[14:11:59] * Lance Stout left the chat.
[14:13:12] * Lance Stout joined the chat.
[14:13:12] * Lance Stout left the chat.
[14:14:16] * Lance Stout joined the chat.
[14:14:39] * Lance Stout left the chat.
[14:14:42] * Lance Stout joined the chat.
[14:14:42] * Lance Stout left the chat.
[14:19:17] * Lance Stout joined the chat.
[14:33:20] * lastsky joined the chat.
[14:36:52] * lastsky left the chat.
[14:38:47] * lastsky joined the chat.
[14:58:25] * Florob left the chat.
[15:04:05] * hawke joined the chat.
[15:04:25] * bjc joined the chat.
[15:04:33] * hawke left the chat.
[15:33:08] * mlundblad_laptop left the chat.
[15:34:37] * jonas left the chat.
[15:47:59] * MattJ joined the chat.
[15:54:47] * evilotto joined the chat.
[16:00:59] * lastsky left the chat.
[16:09:00] * jkhii joined the chat.
[16:18:35] * luca tagliaferri left the chat.
[16:27:20] * luca tagliaferri joined the chat.
[16:29:15] * scippio joined the chat.
[16:29:49] * luca tagliaferri left the chat.
[16:31:19] * tofu left the chat.
[16:31:24] * tofu joined the chat.
[16:49:47] * hawke joined the chat.
[16:51:16] * Tobias joined the chat.
[17:04:16] * smoku left the chat.
[17:08:11] * Treebilou left the chat.
[17:08:14] * petermount left the chat.
[17:42:36] * Florob joined the chat.
[18:16:19] * elmex joined the chat.
[18:17:42] * Neustradamus joined the chat.
[18:21:59] * jkhii joined the chat.
[18:22:56] * alfeberlin joined the chat.
[18:24:02] * tofu joined the chat.
[18:26:16] * jcea joined the chat.
[18:26:40] * hawke joined the chat.
[18:32:24] * zanchin joined the chat.
[18:32:47] * Guus joined the chat.
[18:34:19] * justin joined the chat.
[18:34:33] * Asterix joined the chat.
[18:39:56] * nabatt joined the chat.
[18:42:05] * tofu left the chat.
[18:55:13] * MattJ joined the chat.
[18:57:05] * tofu joined the chat.
[19:01:07] * waqas joined the chat.
[19:02:42] * McKael joined the chat.
[19:03:26] <justin> i am interested in virtual hosting components. right now i'm concerned with the need for a socket per domain
[19:04:01] <waqas> justin: What makes you think there needs to be one socket per domain?
[19:04:30] <justin> it would appear in xep-114 that the connecting component can only assert one domain
[19:05:14] <waqas> Ah, components. Yes, that would be one socket per external component.
[19:05:54] <waqas> Are you interested in a particular component, or does this need to be generic?
[19:05:59] <justin> right. so for example, having extra master domains in the xmpp server, like domain1.com, domain2.com, domain3.com, etc, are pretty much free
[19:06:12] <justin> but having conference.domain1.com, conference.domain2.com, conference.domain3.com.... is totally not
[19:06:46] <waqas> conferences are also free, because pretty much all popular servers have them as internal components, not external.
[19:07:36] <justin> ah ok. i'm curious, is it that way for jabberd too?
[19:07:45] <justin> i wondered how dreamhost had virtual hosted muc for so many years
[19:08:20] <MattJ> No, jabberd doesn't have an internal conference component
[19:08:25] <waqas> No, not for jabberd. Though you can run a separate server (Prosody, ejabberd, whatever) just for conferences, and keep jabberd for primary domains.
[19:09:15] <justin> anyway this does need to be generic. i want to be able to use it for my own components that i am writing
[19:09:48] <justin> xep-225 looked promising
[19:10:07] <waqas> justin: You'll need to write them as internal components. XEP-225 still needs one port per component AFAIK.
[19:10:16] <Guus> the components that you're writing are completely agnostic as for domain-related state?
[19:10:46] <Guus> if so: can't you use s2s instead?
[19:11:03] <MattJ> waqas, 225 allows binding multiple hostnames iirc
[19:11:17] <MattJ> HanzZ wants us to even support it with wildcards in Prosody :)
[19:11:21] <waqas> MattJ: Ah, didn't recall that.
[19:11:22] <justin> Guus: haha, yes, i suppose i could. but that's more work :)
[19:12:35] <Guus> justin: it would avoid any and all complexity that has to do with 'which data relates to what domain' that comes with having one external component serving multiple domains.
[19:13:23] <Guus> I've always seen a component as an entity that enriches the featureset of a particular domain.
[19:13:32] <MattJ> Guus, but it would infinitely easier to implement that in an existing server than implement dialback, etc. from scratch
[19:13:38] <Guus> if you take away that, your external component essentially is another domain.
[19:14:31] <Guus> MattJ: I'
[19:14:33] <Guus> eek
[19:14:36] <MattJ> :)
[19:14:36] <Guus> I'm not following.
[19:14:43] <Guus> ah
[19:14:48] <MattJ> Then perhaps I'm not
[19:14:52] <Guus> well
[19:14:57] * Lance Stout joined the chat.
[19:15:08] <Guus> I am assuming that justin would re-use an existing server implementation, and extend its functionality
[19:15:20] <Guus> either through internal components or whatever plugin architecture
[19:15:51] <Guus> if you're writing the entity from scratch, well, yes, that's going to be hell :)
[19:16:32] * mlundblad joined the chat.
[19:16:35] <waqas> You can probably edit an existing server's component support somewhat to make it support multiple components
[19:16:53] <waqas> *multiple components on a single socket
[19:18:30] <Guus> justin: what kind of functionality are you trying to share amongst domains?
[19:19:55] <justin> i suppose it's best described as very muc-like
[19:22:46] <Guus> does your envisioned external component interact with any of the domains that it serves other than through the external component socket?
[19:23:58] <justin> all through the component socket
[19:24:07] <Guus> you mentioned you were using Whack/Tinder so far. That'd be easy to convert to an Openfire plugin. After that, it's a matter of fixing the addressing (to use the component on another domain rather than on your own) and you should be done.
[19:24:17] <Guus> or am I missing something?
[19:25:13] <waqas> Does Openfire support multiple non-component domains yet?
[19:25:17] <Guus> Whacks external component implementation actually re-uses the Component interface that is used by Openfire (which you will use in the plugin)
[19:25:28] <justin> yes, an internal approach could work. i rather like not being married to a particular server yet (which is why i haven't attempted to make an internal tigase plugin either)
[19:25:41] <Guus> waqas: no
[19:25:45] <Guus> justin, you don't have to
[19:25:57] <Guus> instead of making it a plugin, you can make it an external component too
[19:26:26] <Guus> domainA, domainB, domainC can all talk to an external component on domainZ
[19:28:38] <justin> i don't follow. it already is an external component.
[19:29:05] <Guus> although you're adding an entity, you're not blurring the "what functionailty is made available by which domain" definition, which still bothers me in the 'one component connected to multiple domains' approach
[19:29:15] <Guus> one sec
[19:29:18] <Guus> baby needs food
[19:31:12] <justin> the way i figure it, component domains shouldn't be any more special than the master domains (i use 'master' for lack of a better term)
[19:31:37] <MattJ> Agreed
[19:33:27] <Guus> I disagree. sub.domain.com implies a relation between sub and domain.com
[19:33:43] <MattJ> Guus, what kind of relationship?
[19:34:16] <Guus> parent-child, or some form of partial overlap.
[19:34:57] <MattJ> In Prosody there is no relationship, except at two points... a component will automatically add itself to the disco items of a parent domain (if there is one), and it will automatically inherit SSL certificates
[19:35:40] <waqas> And those exceptions were made only for admin convenience :/
[19:35:43] <MattJ> But they are not parent/child, in that you could deactivate the host and the component would just carry running on as-is
[19:37:42] * nabatt left the chat.
[19:37:45] <Guus> well, I've writting several components that'd only server users local to the 'master/parent' domain, for instance
[19:38:07] <Guus> that's me making use of the relationship as I see it, of course :)
[19:38:09] <MattJ> I've not written any of those so far :)
[19:38:27] <MattJ> But yes, that's fair enough... but still not parent/child in my opinion :)
[19:38:43] <MattJ> I'd say it was parent/child if components couldn't exist without hosts
[19:39:03] <Guus> I'm not sure how you would define parent/child - I simply have no better term for it handy :)
[19:39:53] <MattJ> Well you said you disagree that components shouldn't be "special"
[19:40:45] <MattJ> In Prosody they aren't really special... and they're still too special for our liking, so we're working on changing that :)
[19:40:53] <waqas> Limiting a component to local hosts only is a firewalling thing. In Prosody you'd just disable s2s for them.
[19:40:56] <Guus> in that there is an additional relation defined in a sub-domain.
[19:40:58] <MattJ> Internally they'll just be standard hosts which route differently
[19:41:05] <Guus> "I 'belong' to the master domain"
[19:50:30] <Guus> justin: the approach that you can use without needing to modify any server code, but which does introduce one new component, is this one: apart from all of your current domains, create one new domain. On that domain, implement the functionality that you need. Have users on the original domains talk to the new, service providing domain, for your specific functionality.
[19:51:16] <Guus> (you can, of course, re-use one of the existing domains, but I assume you're looking for dedicated resources as you were implementing something external in the first place)
[19:52:35] <Guus> MattJ: I'm not sure how to put it differently than: I'm looking at sub-domains as addresses that serve functionality that extend the featureset of the domain itself.
[19:52:54] <Guus> this doesn't dictate that the two must overlap, but implies that it can.
[19:53:00] <Guus> at least, to me.
[19:54:04] <Guus> that's what makes components different from two domains exchanging functionality over s2s, in my view.
[19:54:31] <Guus> although I completely agree that for most use cases, there's no difference, functionally.
[19:57:27] <Guus> I bored the crap out of everyone, didn't I? :)
[19:57:33] <justin> yes my usage is very much like an easier version of s2s
[19:58:13] <justin> piggyback on an existing xmpp daemon rather than standalone
[19:59:01] <waqas> Guus: That's how users would view it, sure. But the server software doesn't need to make the parent-child distinction, does it? Does it help in any way (aside from appearing in disco#items)?
[20:00:38] <Guus> waqas: it doesn't need to, no. But specific functionality might want to.
[20:01:42] <waqas> Sure, nothing prevents server plugins from making this distinction.
[20:04:49] <Guus> and that is about the extend of the distinction as I see it. userA@mydomain is less anonymous to comp1.mydomain than it is to comp2.yourdomain. Or, the other way around: comp1.mydomain might treat entities @ mydomain differntly than entities @ yourdomain. It doesn't need to, but it can.
[20:08:56] <Guus> if you're not making use of that distinction, your functionality might as well be accessed over S2S instead of via component addressing. That makes allowing components to multiple domains not needed. If you don't allow that, you can maintain the 'this component might be special to the local domain' concept.
[20:10:31] <waqas> That makes sense. In our case, these would be treated as addon restrictions (e.g., disable s2s, disable all communication except with this domain, etc).
[20:13:38] <Guus> justin: does this help you?
[20:14:54] * Link Mauve joined the chat.
[20:29:29] * Zash joined the chat.
[20:34:02] * SteveG joined the chat.
[20:36:51] <justin> Guus: yes, what you say makes sense. so one approach might be to write internal components with a specific server, and then connect to that server via s2s. then i keep some abstraction
[20:38:08] <justin> but it still feels like a heavy decision. a server implementation has many more moving parts than a component library, that i'd be stuck with
[20:38:59] <justin> so i'd still prefer to do this via a component library if i can. by the way, it seems tigase supports xep-225
[20:39:00] <Guus> justin: I don't think you need internal components 'per server' at all
[20:39:19] <justin> so maybe it would not be too hard to add 225 into whack
[20:40:18] <Guus> in your original plan, users would all refer to a component 'comp@<localdomain>', right?
[20:40:45] <Guus> where, with users, I refer to entities at each of your virtual xmpp servers
[20:40:56] <Guus> (I just assumed they're human users)
[20:42:02] <Guus> if you'd add one more xmpp server (that does not need to have a user base), you can have your component connect to that server only
[20:42:05] <justin> user@example.com would communicate with comp.example2.com
[20:42:26] <Guus> then, over s2s, all users of each of the domains can talk to comp@<remotedomain>
[20:42:46] <justin> ah yes, but then the addressing scheme is different
[20:42:50] <Guus> true
[20:42:58] <Guus> but you can do that without modifying any server-sided code
[20:43:11] <Guus> you can simply create a standard external component
[20:43:26] <Guus> which you can connect to whatever server implementation you like
[20:43:38] <Guus> (provided it supports XEP-0114 of course0
[20:44:42] <justin> well, i'm okay with some coding in order to get this "right"
[20:45:43] <Guus> that's the point I was trying to make earlier - in my opinion, such an approach would be more right than one that requires a component to connect to more than one domain
[20:47:06] <Guus> the addressign scheme is important to you?
[20:48:23] <justin> definitely. in this case i'm trying to retain the scheme from muc: room_name@room_service
[20:48:58] <Guus> and room_service must match the domain of the user that's accessing the functionality?
[20:53:21] * Lance Stout left the chat.
[20:57:59] <justin> no, users from many domains my access the room_service of one domain or others
[20:59:14] <justin> *may access
[21:02:29] * SteveG left the chat.
[21:06:41] <Guus> why then is the addressing scheme not suitable?
[21:07:52] <Guus> I'm now noticing a typo I made earlier. An earlier sentence should have read: "then, over s2s, all users of each of the domains can talk to comp.<remotedomain>"
[21:08:03] <Guus> (instead of comp@<remotedomain>)
[21:08:18] * evilotto joined the chat.
[21:19:07] * Kev joined the chat.
[21:21:16] * johnny joined the chat.
[21:23:08] * waqas left the chat.
[21:24:11] * Tobias joined the chat.
[21:25:10] * Florob joined the chat.
[21:26:49] * scippio joined the chat.
[21:30:34] * SteveG joined the chat.
[21:31:14] <justin> ok yes that's a major typo :)
[21:33:12] <Guus> sorry, it's getting late here :)
[21:38:57] * tofu left the chat.
[21:39:01] * tofu joined the chat.
[21:39:11] * SteveG left the chat.
[21:39:55] * Guus left the chat.
[21:44:24] * SteveG joined the chat.
[21:46:42] * SteveG left the chat.
[21:46:52] * SteveG joined the chat.
[21:51:55] * mlundblad left the chat.
[21:56:16] * SteveG left the chat.
[22:02:29] * Zash left the chat.
[22:16:15] * Lance Stout joined the chat.
[22:20:36] * Tobias left the chat.
[22:22:11] * justin left the chat.
[22:46:42] * deryni joined the chat.
[22:55:57] * jkhii left the chat.
[23:00:11] * Kev left the chat.
[23:05:32] * Zash joined the chat.
[23:16:33] * louiz’ joined the chat.
[23:47:21] * hawke left the chat.
[23:56:39] * rage joined the chat.
[23:57:24] <rage> asdsda
[23:58:05] * rage left the chat.
[00:19:35] * Florob left the chat.
[00:33:49] * evilotto left the chat.
[00:43:56] * jcea left the chat.
[01:40:00] <Zash> fgsfds
[01:41:01] <MattJ> jjjj
[01:56:04] * Zash left the chat.
[01:56:36] * julm joined the chat.
[01:57:45] * julm left the chat.
[02:19:20] * MattJ left the chat.
[03:11:41] * Zash joined the chat.
[03:27:55] * Lance Stout left the chat.
[03:34:40] * nabatt joined the chat.
[03:35:48] * Zash left the chat.
[03:35:52] * Zash joined the chat.
[03:36:02] <Zash> kkkkk
[03:41:04] * Lance Stout joined the chat.
[03:41:16] * Lance Stout left the chat.
[03:41:30] * Lance Stout joined the chat.
[04:19:20] * Zash left the chat.
[04:23:10] * Lance Stout left the chat.
[04:43:38] * scippio left the chat.
[04:53:52] * Treebilou joined the chat.