IRC Archive for channel #xwiki on 06 June 2014
Last modified by Vincent Massol on 2014/06/06 23:59
<Lyes> has left #xwiki
00:09 <Lyes1> has joined #xwiki
00:12 <Lyes1> has quit
00:20 <abusenius> has quit
00:21 <Lyes> has joined #xwiki
00:21 <Lyes> has quit
00:48 <vmassol> has quit
01:01 <lucaa> has quit
01:22 <mflorea> has quit
02:22 <Denis> has quit
04:30 <Denis> has joined #xwiki
06:01 <Denis> has quit
07:15 <D-Spair> has quit
07:15 <sburjan> has quit
07:16 <msmeria> has joined #xwiki
07:26 <sburjan> has joined #xwiki
07:28 <D-Spair> has quit
07:28 <sburjan> has quit
07:33 <sburjan> has joined #xwiki
07:38 <evalica> has joined #xwiki
07:38 <kaisen> has joined #xwiki
08:05 <vmassol> has joined #xwiki
08:11 <kaisen> Good Morning,
08:17 <kaisen> Since I have upgraded to 6.0 I have one Problem when I launcher the Syntax Help. I get the following velocity error http://mysticpaste.com/view/NRJ6ybWc4V?4
08:22 <tmortagne> has joined #xwiki
08:35 <KermitTheFragger> has joined #xwiki
08:40 <evalica> has quit
08:44 <evalica> has joined #xwiki
08:52 <cjd> has joined #xwiki
09:04 <Denis1> has joined #xwiki
09:08 <woshilapin> has joined #xwiki
09:21 <Lyes> has joined #xwiki
09:26 <vmassol> Lyes: good morning
09:26 <vmassol> any progress on the mail api? :)
09:26 <vmassol> do you need some help?
09:27 <Lyes> Vincent: Good Morning
09:29 <Lyes> I was on clients projects
09:32 <vmassol> Lyes: will you be able to work on mail today?
09:32 <vmassol> we need to progress fast now
09:32 <Lyes> Yes i work on it today
09:33 <vmassol> ok cool, let me know if you need help to progress faster
09:46 <mflorea> has joined #xwiki
09:59 <vmassol> goooooood mooooooornnnnniiiiinnnnnng XWiki
09:59 <vmassol> (in the good morning vietnam style ;))
10:00 <cjd> xD
10:01 <cjd> Fighting a war in inhospitable jungle seems an apt metaphore
10:02 <vmassol> :)
10:13 <lucaa> has joined #xwiki
10:27 <lucaa> has quit
10:30 <lucaa> has joined #xwiki
10:33 <vierfzweievieraz> has joined #xwiki
10:47 <kaisen> I will just ask my questions from this moring again in the hope now someone can help me :)
10:47 <kaisen> Since I have upgraded to 6.0 I have one Problem when I launcher the Syntax Help. I get the following velocity error http://mysticpaste.com/view/NRJ6ybWc4V?4
10:51 <evalica> has quit
10:53 <ClemensR> has joined #xwiki
11:04 <silverdrop> has joined #xwiki
11:13 <Denis1> just added what I know of Guillaume work yesterday, no sure it is complete
11:14 <Denis1> is now known as <Denis>
11:15 <vmassol> ah yes thanks Denis (indeed Guillaume is off todayà
11:15 <vmassol> )
11:45 <cjd> mmm
11:45 <webczat> Hello.
11:45 <cjd> Introduce a new Routing Filter <-- this is interesting, it could be a single connection point where all of the servlet crap hands off to our stuff
11:45 <vmassol> almost
11:45 <vmassol> we still need to have 2 servlets
11:46 <vmassol> - struts servlet
11:46 <vmassol> - new xwiki servlet
11:46 <vmassol> for legacy reasons
11:46 <vmassol> if you discard legacy then this single point is the new XWiki Servlet
11:47 <vmassol> RoutingFilter is just there to decide whegher to send to struts or this new servlet based on some conditions
11:47 <cjd> We probably have more power if we use a filter as the entry point as opposed to a servlet
11:47 <vmassol> why?
11:47 <vmassol> they're the same, filter will need to call something :)
11:47 <vmassol> (and this something is a servlet)
11:48 <cjd> filter gets called for any connection that comes in, servlet gets called based on web.xml mapping
11:48 <vmassol> nope
11:48 <vmassol> you have a filter mapping
11:48 <cjd> ahh ok
11:48 <vmassol> they're the same
11:48 <vmassol> the only difference is that filters can be chained
11:49 <vmassol> while servlet are the end of the chain if you prefer
11:49 <cjd> One approach to getting rid of the struts/oldcore stuff would be to work our way down from the top
11:49 <cjd> fake the servlet, then fake struts, then fake oldcore
11:50 <cjd> err fake the servlet container
11:50 <vmassol> the approach I'm taking is create parallel paths
11:50 <vmassol> same as I did for Rendering
11:50 <vmassol> ie support several schemes
11:50 <vmassol> - the current url scheme (currently called "standard")
11:50 <vmassol> - any new scheme
11:50 <vmassol> then provide a nicer new scheme
11:50 <vmassol> at some point make it the default
11:51 <cjd> hm
11:51 <vmassol> and move the "standard" one to legacy/retire it
11:51 <cjd> the hard part is creating the correct context/xwikiservletrequest/etc for oldcore to be happy
11:52 <vmassol> sure
11:52 <vmassol> my goal here
11:52 <vmassol> is not to replace oldcore
11:52 <cjd> +1
11:52 <vmassol> it's to replace the front end part of oldcore (ie struts and XWikiACtion)
11:52 <cjd> IMO you pretty much have to live with XWikiAction
11:52 <cjd> but for what we use struts for, we can probably "mock" it
11:53 <vmassol> I don't understand why we'd need to mock struts, I'm going around it, not needing it
11:53 <cjd> because most of /web/ relies on some little stuff that struts does
11:54 <cjd> not really complex stuff to do otherwise, just little annoying stuff that's just enough to break when you remove it
11:54 <cjd> and IMO replacing oldcore/web/ is a lofty ambition
11:55 <cjd> anyway happy to see this old project coming back again
11:56 <vmassol> the only thing that struts provide IMO is the Form classe, i.e. gather url parameters into a java object
11:56 <cjd> /nod
11:56 <vmassol> not very hard to populate them without struts
11:57 <cjd> yeap, that's basically what I'm getting at re "mocking struts"
11:57 <vmassol> ok
12:04 <webczat> I have concept problems with ldap thing. It will have event listeners that modify directory on modification of user documents. But I am not sure if it is going to seamlessly work with ldap auth plugin.
12:06 <webczat> like the user document is created also after first ldapauth. I can distinguish it because the request has empty password but then passwords go out of sync, actually. like when the user will be subsequently modified etc...
12:07 <webczat> then I would need to distinguish if I want to change password or not.
12:08 <cjd> see the save operation, grab the password, compare it to your ldap container ?
12:09 <webczat> I am not going to have plaintext in ldap, no.
12:09 <webczat> So that makes it impossible especially that I do not want to implement SSHA, would rather like to use password modify op
12:10 <cjd> ahh I see
12:10 <cjd> take the new password, attempt a fake login with ldap
12:11 <cjd> login fail -> update password
12:11 <webczat> I would probably need to either assume xwiki is the only thing that modifies a directory or reimplement auth to be sync aware.
12:11 <webczat> cjd: Really? isn't password hashed in xwiki?
12:12 <webczat> If it has not been modified then
12:12 <cjd> when it's being updated...
12:12 <cjd> you might be able to grab the plaintext, I don't know the code
12:12 <webczat> I believe it is hashed then I can't.
12:13 <webczat> When updating, it is possible but probably only when password changed.
12:13 <cjd> I thought that was the only time you really cared about the update...
12:13 <cjd> if the password is the same, it's not so much of a risk
12:13 <webczat> I didn't do testing yet but I was told it is hashed.
12:14 <cjd> it's single iteration sha512, no salt
12:14 <webczat> remember that I can update realname but leave the password intact
12:14 <cjd> password same in xwiki --> leave password same in ldap?
12:14 <webczat> yes...
12:15 <cjd> you could also put another entry in your ldap dir for the "xwiki hash" which you can always compare to the xwiki hashed password
12:15 <webczat> or if it is still empty, that annoys me that it can be empty
12:15 <cjd> and then it they go out of sync, you can at least know about it
12:17 <webczat> Okay, possible to do but then: how to ensure the whole directory or wiki does not go out of sync? document change/create/delete is one thing. but... first if for example mail in ldap would change
12:17 <webczat> and the user in question would not log in
12:18 <webczat> and someone will try to use the old mail
12:18 <webczat> and: group sync... even worse because adding members should go ti ldap, deleting members should go to ldap, and xwiki should have good info about current members without waiting for all of them to log in.
12:19 <cjd> syncing ldap over to xwiki is something you need to study in your ldap application
12:19 <webczat> cjd: The problem is that it is done only during user loin and that is not a problem when ldap is only read.
12:19 <webczat> *login
12:20 <cjd> sounds like a big project
12:20 <webczat> Unfortunately it is not possible to log into ldap and get events about changes.
12:21 <webczat> I need it for private use.
12:21 <ClemensR> its not possible to get notifications from the ldap ... so it is always possible to go out of sync if you store values from ldap somewhere else ...
12:22 <cjd> it looks like you're going to end up either hacking something together (eg with a script which syncs every so often) or you're going to be stuck rewriting xwiki to defer to ldap
12:22 <webczat> And the main problem is I do not know wiki internals at all.
12:22 <webczat> Or do timed sync.
12:22 <webczat> But...
12:24 <webczat> Also problem, what for group creation and removal... If I would like to make this extension public, some users would like to do it too.
12:26 <webczat> Ahh... If xwiki could implement user managers to completely replace user handling but still allow user edit to be done using standard gui... it would make it easier.
12:26 <webczat> I am blind and do not want to make a gui.
12:29 <webczat> Is there an easier route? there exists a ldap paasword manager with support for self register but without ui for account management.
12:29 <webczat> same for groups.
12:33 <webczat> Okay, I will do the password manager route and disabling user registration somehow. Would be more clean.
12:34 <webczat> hm
12:40 <vmassol> has quit
12:40 <evalica> has joined #xwiki
12:40 <ClemensR> I think adding and removing groups is rather "heavy stuff" and the admins should know what they are doing there. Same for registration: if XWiki users are LDAP synced but registration is still open, then newly registered users will not be in sync with the ldap.
12:41 <ClemensR> That I think is a misconfiguration - Administrators should be told not to do it that way or expect trouble
12:41 <webczat> registering users emits document creating event, doesn't it?
12:41 <ClemensR> yes, I think it does
12:42 <webczat> I mean a sync from xwiki to ldap so it could handle the event.
12:43 <ClemensR> can XWiki write into the LDAP? this of course depends on the settings, but I think in a usual setup it is not possible to write into LDAP. but maybe your use case is different
12:44 <webczat> I thought about writing a component handling events.
12:44 <webczat> It would do ldap sync.
12:45 <webczat> I wouldn't however want to spend half of my life writing that.
12:48 <ClemensR> If you can assume that XWiki, and only XWiki, writes into the ldap, then it is possible to keep them in sync by definition. If you cannot assume that, then the problem is impossible to solve, so no need to worry either ;)
12:49 <webczat> Like document change events for both groups and users would not be so difficult.
12:49 <webczat> I would not add and remove groups, but I could add and remove group members.
12:50 <vmassol> has joined #xwiki
12:51 <webczat> And actually i could live without ldap authentication enabled in xwiki
12:51 <ClemensR> as cjd said, adding a background job to check for inconsistencies between ldap is a manageable hack ... people can at least check if something went inconsistent. That would defer the "impossible" part of the problems to the usrrs ;)
12:51 <evalica> has quit
12:52 <ClemensR> add and remove group members should trigger a DocumentUpdate event on the group, so that is detectable
12:52 <webczat> yes
12:52 <webczat> user add/change/remove too
12:52 <ClemensR> yes
12:53 <webczat> but if any ldap infrastructure changes will haooen or something that would require me to do ldap modify directly.
12:54 <webczat> *happen
12:54 <ClemensR> there is already an ldap authenticator for XWiki, I remember, so people can active that if they want. of course that has the property that if the ldap is down, people with ldap logins cannot login
12:54 <webczat> There is.
12:55 <webczat> ldap authenticator syncs ldap to wiki.
12:55 <ClemensR> but that is normal if you have an ldap for login ... I think
12:55 <webczat> but let's assume I would change ldap admin group using ldap and then
12:56 <webczat> it may be needed due to some external reasons. maybe I should not make this plugin public? I believe it depends a lot on the infrastructure.
12:56 <ClemensR> if folks mess with the admin group in ldap and forgot to update the wiki configuration ...
12:56 <webczat> Or I could defer handling to manual ldap and use another app for password change and user registration
12:57 <webczat> What you think would be a better idea?
12:57 <ClemensR> ... someone will need to activate the "superadmin" account and fix the Mapping "ldap admin" -> XWiki admin, its just that. I you not worry about except mention it loudly in the installation notes
12:58 <webczat> Another thing is:component configuration.
12:59 <ClemensR> I think it depends on the use case. Around here the LDAP is where the admins add new users, so they want no "registration" button in the applications. So they just disable it everywhere they can - and it is easy in XWiki to do that.
12:59 <webczat> Also it would not be a problem if I would use a different ldap lib?
13:00 <webczat> In my case ldap is used for users to have the same accounts on each app, but users have to be able to selfregister.
13:00 <webczat> in general, not on each app
13:02 <ClemensR> well, in that case either they likely register directly in some ldap app, and XWiki has to detect if new users appear on login, i.e. check for them in the LDAP
13:03 <ClemensR> and then you really need to have that background job checking for updates, or you never store any user information in XWiki itself but always fetch it from the LDAP
13:03 <ClemensR> as cjd already said
13:04 <webczat> It would be easier to do. but I would be happy to have the possibility to manage accounts from ui. xwiki does it, but xwiki model is incompatible with ldap and could possibly cause pain.
13:04 <webczat> the auth plugin handles group member sync, handles user info sync and handles user creation on ldap login.
13:05 <ClemensR> ah, yes, I forgot, of course it has to do it
13:05 <webczat> That made me think about making a component that handles user sync automatically so that the wiki registers users.
13:06 <webczat> It does not change the fact that a separate ldap app is probably more clean, always up to date etc.
13:06 <webczat> Although xwiki may go out of sync, ldap cannot.
13:09 <webczat> In the case of a component, if I would deny the whole operation on ldap malfunction, ldap couldn't go out of sync, but modifying ldap directly would have higher impact on the wiki if the same thing would be subsequently modified in wiki.
13:09 <vierfzweievieraz> has left #xwiki
13:10 <webczat> like group member added in ldap, then group member (another one) removed in wiki. means both removed from ldap.
13:11 <webczat> Because it would be difficult to get a change of a whole document and distinguish between add of members and such, so I would issue attribute replace with the whole list.
13:12 <OSIMasson> has quit
13:13 <ClemensR> in DocumentUpdatedEvents you can also get the wiki doc before the change with doc.getOriginalDocument(), so you can compare that with the ldap and see it it is already put of sync
13:14 <ClemensR> not sure if that helps much ... but at least you could both figure out if you are in sync and what the actual change in that update is
13:14 <ClemensR> oh and "put of sync" should read "out of sync", sorry
13:23 <webczat> still wondering what to do.
13:23 <webczat> if it's worth making something like that
13:25 <webczat> Because it is actually a hack over hack. like do not sync user when document creating event was received without a password because this is the user creation during ldap auth.
13:26 <webczat> when login process updates the document then first data are downloaded from ldap then because I cannot distinguish between profile change and ldapauth sync, the same data is copied again to ldap. It wouldn't cause a problem but even sounds strange.
13:51 <Denis> has quit
13:52 <webczat> What would you do in my case?
13:56 <Denis> has joined #xwiki
14:20 <KermitTheFragger> has quit
14:32 <ClemensR> has left #xwiki
14:53 <msmeria> has quit
15:40 <cjd> vmassol: for configuration of filesystem attachments, store.fsattach.myConfigurationKey ?
15:40 <cjd> WDYT?
16:10 <cjd> tmortagne: since vmassol seems to be afk and I'm itching to commit, WDYT of store.fsattach.cleanOnStartup as a configuration key?
16:10 <cjd> specifically store.fsattach as a prefix for filesystem attachment related config
16:12 <tmortagne> looks good to me
16:12 <cjd> cool, thanks
16:20 <Denis> has quit
16:21 <vmassol> cjd: I haven't followed but I've just read the RN
16:22 <vmassol> and I have a question
16:22 <vmassol> if the FS auto clean is not required to work then why not drop it?
16:22 <vmassol> if it's needed then it should be even more needed on systems where you have lots of attachments, no?
16:23 <cjd> vmassol: because administrators who are in the know can decide to clean empty directories in a different way, for example at 2:00AM when there is minimum load on the server
16:24 <cjd> however I think that just putting it in a thread will alleviate the issue, the configuration parameter is a safty measure
16:24 <cjd> and yes, I forgot to add the line to xwiki.properties, doing that now
16:26 <cjd> ./xwiki-platform-tools/xwiki-platform-tool-configuration-resources/src/main/resources/xwiki.properties.vm <-- This one is correct I presume
16:29 <tmortagne> yes
16:30 <cjd> meh I kind of have to start a new section for storage
16:30 <cjd> annoying but there's nothing else that really fits
16:34 <vmassol> cjd: hmm
16:35 <cjd> :D
16:35 <cjd> I knew it
16:35 <vmassol> isn't our storage config in xwiki.cfg.vm?
16:35 <cjd> all I'd have to do is push and you'd find something you didn't like
16:35 <vmassol> this is oldcore no?
16:35 <cjd> nope
16:35 <cjd> xwiki-platform-store
16:35 <vmassol> and platform-store has not config so far?
16:35 <vmassol> s/not/no
16:35 <cjd> correct
16:36 <vmassol> ok
16:36 <cjd> well until 5 minutes ago
16:37 <vmassol> you should be glad that people are willing to spend time to review what you do
16:37 <cjd> Yeah, I do appreciate the effort :)
16:39 <vmassol> maybe I'm a PITA but that's mostly because I want to understand so that I can maintain it afterwards (ie answer questions, etc)
16:39 <cjd> That's valid
16:41 <cjd> The only thing I would suggest (and feel free to trash it if you like) is that it's important not to get trapped in comment typos and variable naming as much as the big stuff like promiscuous globals...
16:42 <vmassol> ideally yes, although variable naming can be important. Reviewing design is several order of magnitude more complex so that's why there's more comment on the small things. I understand though
16:43 <vmassol> globally that reminds me Freakonomics
16:43 <vmassol> have you read that book?
16:43 <vmassol> they mention about the new work metro
16:43 <vmassol> and the fact that there's violence and it's dirty, etc
16:44 <Slashman> has joined #xwiki
16:44 <vmassol> and the study shows that if you let a few people get away with tagging the walls and deteriorating stuff
16:44 <vmassol> very quickly everyone does it
16:44 <vmassol> and insecurity increases
16:45 <vmassol> I feel it's a bit the same about a code base
16:45 <vmassol> and when you have stuff like the oldcore then nobody wants to work on it anymore…
16:46 <vmassol> when stuff are inconsistent, hack over hack, no doc, bad var naming
16:46 <vmassol> then you get a bad feeling
16:46 <vmassol> and then
16:46 <vmassol> either you don't want to touch that code
16:46 <vmassol> or when you have to do it, you keep doing the same thing as what is there already and you even increase the technical debt
16:47 <vmassol> because it's alreadhy "dirty" so making it a little bit more dirty seems ok
16:48 <vmassol> when you have clean code you want to continue keeping it clean and you have remorse if you don't ;)
16:49 <vmassol> don't you agree?
16:50 <vmassol> said differently, I'm a believer that small things matter and can have big effects. Now we need to not piss off the contributors/committers....
16:50 <vmassol> :)
16:51 <vmassol> that's the hard part...
16:53 <tmortagne> has quit
16:53 <cjd> sorry I was just away for a moment
16:54 <cjd> ahh the "broken windows" theory
16:54 <cjd> indeed things getting chaotic is a bad thing
16:55 <cjd> Actually I think the problem with oldcore is more because of difficulty to validate and test, and fear of breaking backward compat
16:55 <cjd> build performance comes in here ;)
16:55 <vmassol> it's more missing tests
16:56 <vmassol> but you can't add tests easily because of the design
16:56 <cjd> difficulty to validate is missing tests
16:56 <cjd> and difficulty to test is ... yeah
16:56 <vmassol> but when you read the code you also get a lot of WTF moments…
16:57 <cjd> That happens when I read any code :|
16:57 <vmassol> like XWiki.getFlash()
16:57 <vmassol> ;)
16:59 <cjd> yeah, getFlash is cutting across boundries between view and controller
17:00 <vmassol> and there's no flash.vm AFAIK ...
17:00 <cjd> /nod
17:00 <cjd> so one problem is that we don't have a clear vision of what is actually being used and what is just sitting there
17:00 <cjd> if we did, we could clean things up significantly be summarily yanking anything which is in a "doesn't work, noone uses it, may never have worked" state
17:01 <vmassol> for this method actually we should move it to legacy
17:01 <cjd> but that takes courage which takes a fast build/test cycle :)
17:01 <cjd> and lots of tests
17:02 <vmassol> a quick grep shows it's not used anywhere, will move now actually! :)
17:03 <cjd> One night I was thinking about what I would do if suddenly I had to do your job. The first answer that came to my mind was "work nights for a long time" ;)
17:04 <cjd> many many scripts running over the codebase looking for things which can be fixed
17:04 <vmassol> yeah it might be a good idea to switch jobs actually, as you get blunted over time
17:04 <cjd> bring hellfire upon the build time
17:05 <vmassol> every few weeks I ask myself whether I'm doing a good job or not
17:05 <cjd> oh hell, don't start going there
17:05 <vmassol> and I have ups and downs…
17:05 <cjd> you're good
17:05 <vmassol> actually I'm not sure
17:05 <vmassol> it's been 7 years for me
17:05 <vmassol> and I was not able to do half of what I wanted to do
17:06 <cjd> :(
17:06 <vmassol> and xwiki is still not yet known worldwide… :)
17:06 <ClemensR> has joined #xwiki
17:06 <cjd> we'll get there on the second part
17:06 <cjd> first part, all I have to say is feed that inner anger at how much everything sucks
17:07 <cjd> because everything in the world is really not that great, not just software either
17:07 <cjd> guys building libraries don't know your pain when you use them, people building the tools don't know it either
17:08 <cjd> Remember yesterday you were talking about reinventing everything and I said "there has to be a limit"?
17:09 <cjd> I thought about that and I was wrong. There should be no limit at all. Do one thing at a time, start with the low hanging fruit, and there's no good reason why making *everything* better is not valid.
17:09 <vmassol> yup and I think as you get older your past experience pushes that limit down and to make some dent in the world you prefer focusing on more narrow things because you're more likely to succeed
17:10 <vmassol> now if you're in pure research then of course you have a lot more liberty
17:10 <vmassol> than you have if you need to support a user base....
17:11 <cjd> And cjdns is a unique thing because it has almost no backward compat to support so I can sneak off with some horrific tricks
17:11 <cjd> XWiki is a different story alltogether
17:11 <vmassol> that's the pain of getting old… you're getting too realistic :)
17:11 <vmassol> I love this quote:
17:11 <cjd> but not a challenge we can't beat
17:11 <vmassol> (translated from french)
17:12 <cjd> :)
17:12 <vmassol> "they didn't know it was impossible and thus they did it"
17:12 <cjd> ahh
17:13 <cjd> Those who say it can't be done should get out of the way of those who are doing it.
17:13 <cjd> --Joel Arthur Barker
17:13 <cjd> Lot of truth to those words
17:14 <vmassol> yes it's a nice quote, all is about the context and the goal…
17:14 <cjd> On my side, I do things which nobody thought of, stuff like planting the websocket directly into XWiki instead of waiting for tomcat to come along with a version which supports it
17:14 <kaisen> has quit
17:15 <cjd> and I pay my share because I have to debug my code more
17:15 <cjd> but I get it all back in the end because once I've debugged it, it's clean and I don't usually end up dealing with uglyness because someone decided to use glassfish...
17:16 <cjd> but it requires courage because when I screw up and try to do something that can't be done and it actually can't be done, I fall on my face
17:16 <vmassol> it's like our wysiwyg
17:16 <vmassol> it was nice to reimplment it initially because it brought us an edge over others at the time
17:17 <vmassol> but since it's not our core business we don't invest in it and thus we loose ground over time
17:17 <vmassol> and then it becomes a burden becuase others are overcaught you
17:17 <vmassol> and you need to pay again for removing it
17:17 <vmassol> so you better profit from the initial advantage you had or it's not worth it
17:17 <cjd> +1 that
17:17 <cjd> so we switch to a generic editor and sell the fact that XWiki is the Realtime Wiki :D
17:18 <vmassol> :)
17:18 <cjd> btw I have a couple of silly bugs to fix and then WDYT of realtime-wiki on xwiki.org?
17:19 <vmassol> if you think it's ready enough then it would be great
17:19 <vmassol> maybe on myxwiki.org first though
17:19 <vmassol> since myxwiki.org is our rea world test platform
17:19 <cjd> I think it's ready for anything
17:19 <vmassol> and then if it works fine, we can have it on xwiki.org
17:20 <cjd> all of the bugs I've discovered have been "haha I didn't think of that", nothing core level or algorithmic
17:20 <cjd> that sounds like a logical approach
17:20 <cjd> oh I really wanna do chat :D
17:21 <vmassol> wdym?
17:21 <vmassol> chat in the wiki?
17:21 <cjd> userlink -> "this user is online, chat?"
17:21 <mflorea> has quit
17:21 <vmassol> ah like fabio's extension?
17:21 <cjd> yes
17:21 <vmassol> http://extensions.xwiki.org/xwiki/bin/view/Extension/XMPP+Chat+Application
17:21 <vmassol> ?
17:21 <cjd> except since I have a well tested websocket which is capable of doing arbitrary backends, this time it will be easy
17:22 <cjd> if realtime wiki works, chat is "free"
17:22 <vmassol> cool
17:22 <cjd> video chat is not that interesting to me atm
17:22 <vmassol> sure I agree
17:22 <cjd> ideally we train people to chat in text and then enable logging so it can be searched
17:23 <cjd> [ ] Off The Record (unchecked by default so everything is logged)
17:25 <cjd> also we're going to wipe the floor with the competition when we have pervasive realtime/websocket stuff because all of the other stuff *cough* jira is basically like a struts app with some js sugar
17:25 <vmassol> :)
17:25 <cjd> like the recent changes don't auto-update, wat is this?!
17:26 <vmassol> yes that would be nice but we need to rewrite the AS first
17:27 <cjd> can we fire events and then just listen for them?
17:27 <vmassol> that's what the AS does
17:27 <vmassol> it listens to all events
17:27 <vmassol> and displays them
17:27 <cjd> ahh ok then all we need to do is listen to events and bcast them down the websocket
17:27 <cjd> even allow the client to listen for events in js using a WebSocketHandler
17:28 <vmassol> sure what I mean is that are lots of issues with the AS, first being performances
17:28 <cjd> /nod
17:28 <vmassol> so we need to rewrite it anyway
17:28 <vmassol> so if you improve it now then when we rewrite you have to rewrite more
17:28 <vmassol> I've been trying to try to fit thre rewrite in the roadmap several times already
17:28 <cjd> ahh everything would be so much easier if we just shoehored nodejs into a .jar file and tricked the customers into thinking it's struts
17:28 <vmassol> almost succeedd twice
17:28 <vmassol> ...
17:29 <vmassol> I'll continue trying and in the end I'll prevail… ;)
17:29 <cjd> careful of the bulldozer approach
17:30 <cjd> don't want you to burn out, you're our General
17:30 <vmassol> yeah that's a possibility on the long run...
17:31 <cjd> bulldozer or sneeky.js ?
17:31 <vmassol> wearing out
17:31 <cjd> I'm not gonna let you :P
17:32 <vmassol> :)
17:33 <vmassol> [friday fun] http://t.co/SQmFJIgUdA
17:33 <cjd> I was thinking, we should probably find the best technology (not the most fastionable) and use that, then we should wrap that technology in whatever our customers want
17:34 <cjd> haha
17:36 <vmassol> ‘Write clear, precise code. Every ten years it will run 1,000 times faster.’—Joe Armstrong
17:37 <cjd> write the cheapest code to develop and maintain until it's out of date
17:37 <cjd> cheap to develop implies a higher maintanence cost so it's a balance
17:37 <cjd> but in the end, everything is a prototype
17:41 <cjd> also play with nodejs, I'm to the point now of being willing to bet money that in 10 years it's going to beat everything else, it's also a lot of fun :)
17:42 <vmassol> the problem is that you're just thinking about node.js but you're not thinking about tools/educating developers/ability to recruit devleopers who know the technology/etc
17:43 <vmassol> you really need to factor all this in
17:43 <cjd> +1 that
17:43 <vmassol> at XWiki SAS for ex we have python code
17:43 <cjd> I'm just saying fool around with it :)
17:43 <vmassol> and nobody is touhcing it because nobody knows it
17:43 <vmassol> and it's decaying
17:44 <vmassol> fooling around is ok
17:44 <vmassol> :)
17:44 <cjd> I volunteered to help look at it even though I'm not a python expert
17:44 <cjd> I like a challenge
17:44 <vmassol> cool
17:44 <cjd> they said it's ok so I didn't persue it
17:44 <cjd> the problem I saw was threading, threads make everything harder to reason with
17:45 <cjd> (with the python thingy)
18:04 <mflorea> has joined #xwiki
18:20 <ClemensR> has left #xwiki
19:04 <mflorea> has quit
19:09 <vmassol> Lyes: missing @Component and @Singleton, adding now
19:15 <cjd> has quit
19:19 <lucaa> has quit
19:19 <woshilapin> has quit
19:19 <vmassol> Lyes: ok I'm done with a first quick review :)
19:20 <vmassol> a few things to fix...
19:20 <vmassol> :)
19:20 <Lyes> i check your comments
19:25 <Slashman> has quit
19:37 <lucaa> has joined #xwiki
19:37 <abusenius> has joined #xwiki
19:41 <vmassol> cjd
19:41 <vmassol> not here....
19:48 <silverdrop> has quit
19:49 <abusenius> has quit
19:53 <silverdrop> has joined #xwiki
20:06 <ramkamx> has quit
20:33 <vmassol> has quit
20:40 <vmassol> has joined #xwiki
20:53 <silverdrop> has quit
20:59 <abusenius> has joined #xwiki
21:14 <silverdrop> has joined #xwiki
21:23 <silverdrop> has quit
21:34 <lucaa> has quit
22:26 <tekzilla> has quit
22:34 <tekzilla> has joined #xwiki
23:01 <vmassol> has quit
23:50 <vmassol> has joined #xwiki
23:59 <vmassol> has quit
00:09 <Lyes1> has joined #xwiki
00:12 <Lyes1> has quit
00:20 <abusenius> has quit
00:21 <Lyes> has joined #xwiki
00:21 <Lyes> has quit
00:48 <vmassol> has quit
01:01 <lucaa> has quit
01:22 <mflorea> has quit
02:22 <Denis> has quit
04:30 <Denis> has joined #xwiki
06:01 <Denis> has quit
07:15 <D-Spair> has quit
07:15 <sburjan> has quit
07:16 <msmeria> has joined #xwiki
07:26 <sburjan> has joined #xwiki
07:28 <D-Spair> has quit
07:28 <sburjan> has quit
07:33 <sburjan> has joined #xwiki
07:38 <evalica> has joined #xwiki
07:38 <kaisen> has joined #xwiki
08:05 <vmassol> has joined #xwiki
08:11 <kaisen> Good Morning,
08:17 <kaisen> Since I have upgraded to 6.0 I have one Problem when I launcher the Syntax Help. I get the following velocity error http://mysticpaste.com/view/NRJ6ybWc4V?4
08:22 <tmortagne> has joined #xwiki
08:35 <KermitTheFragger> has joined #xwiki
08:40 <evalica> has quit
08:44 <evalica> has joined #xwiki
08:52 <cjd> has joined #xwiki
09:04 <Denis1> has joined #xwiki
09:08 <woshilapin> has joined #xwiki
09:21 <Lyes> has joined #xwiki
09:26 <vmassol> Lyes: good morning
09:26 <vmassol> any progress on the mail api? :)
09:26 <vmassol> do you need some help?
09:27 <Lyes> Vincent: Good Morning
09:29 <Lyes> I was on clients projects
09:32 <vmassol> Lyes: will you be able to work on mail today?
09:32 <vmassol> we need to progress fast now
09:32 <Lyes> Yes i work on it today
09:33 <vmassol> ok cool, let me know if you need help to progress faster
09:46 <mflorea> has joined #xwiki
09:59 <vmassol> goooooood mooooooornnnnniiiiinnnnnng XWiki
09:59 <vmassol> (in the good morning vietnam style ;))
10:00 <cjd> xD
10:01 <cjd> Fighting a war in inhospitable jungle seems an apt metaphore
10:02 <vmassol> :)
10:13 <lucaa> has joined #xwiki
10:27 <lucaa> has quit
10:30 <lucaa> has joined #xwiki
10:33 <vierfzweievieraz> has joined #xwiki
10:47 <kaisen> I will just ask my questions from this moring again in the hope now someone can help me :)
10:47 <kaisen> Since I have upgraded to 6.0 I have one Problem when I launcher the Syntax Help. I get the following velocity error http://mysticpaste.com/view/NRJ6ybWc4V?4
10:51 <evalica> has quit
10:53 <ClemensR> has joined #xwiki
11:04 <silverdrop> has joined #xwiki
11:13 <Denis1> just added what I know of Guillaume work yesterday, no sure it is complete
11:14 <Denis1> is now known as <Denis>
11:15 <vmassol> ah yes thanks Denis (indeed Guillaume is off todayà
11:15 <vmassol> )
11:45 <cjd> mmm
11:45 <webczat> Hello.
11:45 <cjd> Introduce a new Routing Filter <-- this is interesting, it could be a single connection point where all of the servlet crap hands off to our stuff
11:45 <vmassol> almost
11:45 <vmassol> we still need to have 2 servlets
11:46 <vmassol> - struts servlet
11:46 <vmassol> - new xwiki servlet
11:46 <vmassol> for legacy reasons
11:46 <vmassol> if you discard legacy then this single point is the new XWiki Servlet
11:47 <vmassol> RoutingFilter is just there to decide whegher to send to struts or this new servlet based on some conditions
11:47 <cjd> We probably have more power if we use a filter as the entry point as opposed to a servlet
11:47 <vmassol> why?
11:47 <vmassol> they're the same, filter will need to call something :)
11:47 <vmassol> (and this something is a servlet)
11:48 <cjd> filter gets called for any connection that comes in, servlet gets called based on web.xml mapping
11:48 <vmassol> nope
11:48 <vmassol> you have a filter mapping
11:48 <cjd> ahh ok
11:48 <vmassol> they're the same
11:48 <vmassol> the only difference is that filters can be chained
11:49 <vmassol> while servlet are the end of the chain if you prefer
11:49 <cjd> One approach to getting rid of the struts/oldcore stuff would be to work our way down from the top
11:49 <cjd> fake the servlet, then fake struts, then fake oldcore
11:50 <cjd> err fake the servlet container
11:50 <vmassol> the approach I'm taking is create parallel paths
11:50 <vmassol> same as I did for Rendering
11:50 <vmassol> ie support several schemes
11:50 <vmassol> - the current url scheme (currently called "standard")
11:50 <vmassol> - any new scheme
11:50 <vmassol> then provide a nicer new scheme
11:50 <vmassol> at some point make it the default
11:51 <cjd> hm
11:51 <vmassol> and move the "standard" one to legacy/retire it
11:51 <cjd> the hard part is creating the correct context/xwikiservletrequest/etc for oldcore to be happy
11:52 <vmassol> sure
11:52 <vmassol> my goal here
11:52 <vmassol> is not to replace oldcore
11:52 <cjd> +1
11:52 <vmassol> it's to replace the front end part of oldcore (ie struts and XWikiACtion)
11:52 <cjd> IMO you pretty much have to live with XWikiAction
11:52 <cjd> but for what we use struts for, we can probably "mock" it
11:53 <vmassol> I don't understand why we'd need to mock struts, I'm going around it, not needing it
11:53 <cjd> because most of /web/ relies on some little stuff that struts does
11:54 <cjd> not really complex stuff to do otherwise, just little annoying stuff that's just enough to break when you remove it
11:54 <cjd> and IMO replacing oldcore/web/ is a lofty ambition
11:55 <cjd> anyway happy to see this old project coming back again
11:56 <vmassol> the only thing that struts provide IMO is the Form classe, i.e. gather url parameters into a java object
11:56 <cjd> /nod
11:56 <vmassol> not very hard to populate them without struts
11:57 <cjd> yeap, that's basically what I'm getting at re "mocking struts"
11:57 <vmassol> ok
12:04 <webczat> I have concept problems with ldap thing. It will have event listeners that modify directory on modification of user documents. But I am not sure if it is going to seamlessly work with ldap auth plugin.
12:06 <webczat> like the user document is created also after first ldapauth. I can distinguish it because the request has empty password but then passwords go out of sync, actually. like when the user will be subsequently modified etc...
12:07 <webczat> then I would need to distinguish if I want to change password or not.
12:08 <cjd> see the save operation, grab the password, compare it to your ldap container ?
12:09 <webczat> I am not going to have plaintext in ldap, no.
12:09 <webczat> So that makes it impossible especially that I do not want to implement SSHA, would rather like to use password modify op
12:10 <cjd> ahh I see
12:10 <cjd> take the new password, attempt a fake login with ldap
12:11 <cjd> login fail -> update password
12:11 <webczat> I would probably need to either assume xwiki is the only thing that modifies a directory or reimplement auth to be sync aware.
12:11 <webczat> cjd: Really? isn't password hashed in xwiki?
12:12 <webczat> If it has not been modified then
12:12 <cjd> when it's being updated...
12:12 <cjd> you might be able to grab the plaintext, I don't know the code
12:12 <webczat> I believe it is hashed then I can't.
12:13 <webczat> When updating, it is possible but probably only when password changed.
12:13 <cjd> I thought that was the only time you really cared about the update...
12:13 <cjd> if the password is the same, it's not so much of a risk
12:13 <webczat> I didn't do testing yet but I was told it is hashed.
12:14 <cjd> it's single iteration sha512, no salt
12:14 <webczat> remember that I can update realname but leave the password intact
12:14 <cjd> password same in xwiki --> leave password same in ldap?
12:14 <webczat> yes...
12:15 <cjd> you could also put another entry in your ldap dir for the "xwiki hash" which you can always compare to the xwiki hashed password
12:15 <webczat> or if it is still empty, that annoys me that it can be empty
12:15 <cjd> and then it they go out of sync, you can at least know about it
12:17 <webczat> Okay, possible to do but then: how to ensure the whole directory or wiki does not go out of sync? document change/create/delete is one thing. but... first if for example mail in ldap would change
12:17 <webczat> and the user in question would not log in
12:18 <webczat> and someone will try to use the old mail
12:18 <webczat> and: group sync... even worse because adding members should go ti ldap, deleting members should go to ldap, and xwiki should have good info about current members without waiting for all of them to log in.
12:19 <cjd> syncing ldap over to xwiki is something you need to study in your ldap application
12:19 <webczat> cjd: The problem is that it is done only during user loin and that is not a problem when ldap is only read.
12:19 <webczat> *login
12:20 <cjd> sounds like a big project
12:20 <webczat> Unfortunately it is not possible to log into ldap and get events about changes.
12:21 <webczat> I need it for private use.
12:21 <ClemensR> its not possible to get notifications from the ldap ... so it is always possible to go out of sync if you store values from ldap somewhere else ...
12:22 <cjd> it looks like you're going to end up either hacking something together (eg with a script which syncs every so often) or you're going to be stuck rewriting xwiki to defer to ldap
12:22 <webczat> And the main problem is I do not know wiki internals at all.
12:22 <webczat> Or do timed sync.
12:22 <webczat> But...
12:24 <webczat> Also problem, what for group creation and removal... If I would like to make this extension public, some users would like to do it too.
12:26 <webczat> Ahh... If xwiki could implement user managers to completely replace user handling but still allow user edit to be done using standard gui... it would make it easier.
12:26 <webczat> I am blind and do not want to make a gui.
12:29 <webczat> Is there an easier route? there exists a ldap paasword manager with support for self register but without ui for account management.
12:29 <webczat> same for groups.
12:33 <webczat> Okay, I will do the password manager route and disabling user registration somehow. Would be more clean.
12:34 <webczat> hm
12:40 <vmassol> has quit
12:40 <evalica> has joined #xwiki
12:40 <ClemensR> I think adding and removing groups is rather "heavy stuff" and the admins should know what they are doing there. Same for registration: if XWiki users are LDAP synced but registration is still open, then newly registered users will not be in sync with the ldap.
12:41 <ClemensR> That I think is a misconfiguration - Administrators should be told not to do it that way or expect trouble
12:41 <webczat> registering users emits document creating event, doesn't it?
12:41 <ClemensR> yes, I think it does
12:42 <webczat> I mean a sync from xwiki to ldap so it could handle the event.
12:43 <ClemensR> can XWiki write into the LDAP? this of course depends on the settings, but I think in a usual setup it is not possible to write into LDAP. but maybe your use case is different
12:44 <webczat> I thought about writing a component handling events.
12:44 <webczat> It would do ldap sync.
12:45 <webczat> I wouldn't however want to spend half of my life writing that.
12:48 <ClemensR> If you can assume that XWiki, and only XWiki, writes into the ldap, then it is possible to keep them in sync by definition. If you cannot assume that, then the problem is impossible to solve, so no need to worry either ;)
12:49 <webczat> Like document change events for both groups and users would not be so difficult.
12:49 <webczat> I would not add and remove groups, but I could add and remove group members.
12:50 <vmassol> has joined #xwiki
12:51 <webczat> And actually i could live without ldap authentication enabled in xwiki
12:51 <ClemensR> as cjd said, adding a background job to check for inconsistencies between ldap is a manageable hack ... people can at least check if something went inconsistent. That would defer the "impossible" part of the problems to the usrrs ;)
12:51 <evalica> has quit
12:52 <ClemensR> add and remove group members should trigger a DocumentUpdate event on the group, so that is detectable
12:52 <webczat> yes
12:52 <webczat> user add/change/remove too
12:52 <ClemensR> yes
12:53 <webczat> but if any ldap infrastructure changes will haooen or something that would require me to do ldap modify directly.
12:54 <webczat> *happen
12:54 <ClemensR> there is already an ldap authenticator for XWiki, I remember, so people can active that if they want. of course that has the property that if the ldap is down, people with ldap logins cannot login
12:54 <webczat> There is.
12:55 <webczat> ldap authenticator syncs ldap to wiki.
12:55 <ClemensR> but that is normal if you have an ldap for login ... I think
12:55 <webczat> but let's assume I would change ldap admin group using ldap and then
12:56 <webczat> it may be needed due to some external reasons. maybe I should not make this plugin public? I believe it depends a lot on the infrastructure.
12:56 <ClemensR> if folks mess with the admin group in ldap and forgot to update the wiki configuration ...
12:56 <webczat> Or I could defer handling to manual ldap and use another app for password change and user registration
12:57 <webczat> What you think would be a better idea?
12:57 <ClemensR> ... someone will need to activate the "superadmin" account and fix the Mapping "ldap admin" -> XWiki admin, its just that. I you not worry about except mention it loudly in the installation notes
12:58 <webczat> Another thing is:component configuration.
12:59 <ClemensR> I think it depends on the use case. Around here the LDAP is where the admins add new users, so they want no "registration" button in the applications. So they just disable it everywhere they can - and it is easy in XWiki to do that.
12:59 <webczat> Also it would not be a problem if I would use a different ldap lib?
13:00 <webczat> In my case ldap is used for users to have the same accounts on each app, but users have to be able to selfregister.
13:00 <webczat> in general, not on each app
13:02 <ClemensR> well, in that case either they likely register directly in some ldap app, and XWiki has to detect if new users appear on login, i.e. check for them in the LDAP
13:03 <ClemensR> and then you really need to have that background job checking for updates, or you never store any user information in XWiki itself but always fetch it from the LDAP
13:03 <ClemensR> as cjd already said
13:04 <webczat> It would be easier to do. but I would be happy to have the possibility to manage accounts from ui. xwiki does it, but xwiki model is incompatible with ldap and could possibly cause pain.
13:04 <webczat> the auth plugin handles group member sync, handles user info sync and handles user creation on ldap login.
13:05 <ClemensR> ah, yes, I forgot, of course it has to do it
13:05 <webczat> That made me think about making a component that handles user sync automatically so that the wiki registers users.
13:06 <webczat> It does not change the fact that a separate ldap app is probably more clean, always up to date etc.
13:06 <webczat> Although xwiki may go out of sync, ldap cannot.
13:09 <webczat> In the case of a component, if I would deny the whole operation on ldap malfunction, ldap couldn't go out of sync, but modifying ldap directly would have higher impact on the wiki if the same thing would be subsequently modified in wiki.
13:09 <vierfzweievieraz> has left #xwiki
13:10 <webczat> like group member added in ldap, then group member (another one) removed in wiki. means both removed from ldap.
13:11 <webczat> Because it would be difficult to get a change of a whole document and distinguish between add of members and such, so I would issue attribute replace with the whole list.
13:12 <OSIMasson> has quit
13:13 <ClemensR> in DocumentUpdatedEvents you can also get the wiki doc before the change with doc.getOriginalDocument(), so you can compare that with the ldap and see it it is already put of sync
13:14 <ClemensR> not sure if that helps much ... but at least you could both figure out if you are in sync and what the actual change in that update is
13:14 <ClemensR> oh and "put of sync" should read "out of sync", sorry
13:23 <webczat> still wondering what to do.
13:23 <webczat> if it's worth making something like that
13:25 <webczat> Because it is actually a hack over hack. like do not sync user when document creating event was received without a password because this is the user creation during ldap auth.
13:26 <webczat> when login process updates the document then first data are downloaded from ldap then because I cannot distinguish between profile change and ldapauth sync, the same data is copied again to ldap. It wouldn't cause a problem but even sounds strange.
13:51 <Denis> has quit
13:52 <webczat> What would you do in my case?
13:56 <Denis> has joined #xwiki
14:20 <KermitTheFragger> has quit
14:32 <ClemensR> has left #xwiki
14:53 <msmeria> has quit
15:40 <cjd> vmassol: for configuration of filesystem attachments, store.fsattach.myConfigurationKey ?
15:40 <cjd> WDYT?
16:10 <cjd> tmortagne: since vmassol seems to be afk and I'm itching to commit, WDYT of store.fsattach.cleanOnStartup as a configuration key?
16:10 <cjd> specifically store.fsattach as a prefix for filesystem attachment related config
16:12 <tmortagne> looks good to me
16:12 <cjd> cool, thanks
16:20 <Denis> has quit
16:21 <vmassol> cjd: I haven't followed but I've just read the RN
16:22 <vmassol> and I have a question
16:22 <vmassol> if the FS auto clean is not required to work then why not drop it?
16:22 <vmassol> if it's needed then it should be even more needed on systems where you have lots of attachments, no?
16:23 <cjd> vmassol: because administrators who are in the know can decide to clean empty directories in a different way, for example at 2:00AM when there is minimum load on the server
16:24 <cjd> however I think that just putting it in a thread will alleviate the issue, the configuration parameter is a safty measure
16:24 <cjd> and yes, I forgot to add the line to xwiki.properties, doing that now
16:26 <cjd> ./xwiki-platform-tools/xwiki-platform-tool-configuration-resources/src/main/resources/xwiki.properties.vm <-- This one is correct I presume
16:29 <tmortagne> yes
16:30 <cjd> meh I kind of have to start a new section for storage
16:30 <cjd> annoying but there's nothing else that really fits
16:34 <vmassol> cjd: hmm
16:35 <cjd> :D
16:35 <cjd> I knew it
16:35 <vmassol> isn't our storage config in xwiki.cfg.vm?
16:35 <cjd> all I'd have to do is push and you'd find something you didn't like
16:35 <vmassol> this is oldcore no?
16:35 <cjd> nope
16:35 <cjd> xwiki-platform-store
16:35 <vmassol> and platform-store has not config so far?
16:35 <vmassol> s/not/no
16:35 <cjd> correct
16:36 <vmassol> ok
16:36 <cjd> well until 5 minutes ago
16:37 <vmassol> you should be glad that people are willing to spend time to review what you do
16:37 <cjd> Yeah, I do appreciate the effort :)
16:39 <vmassol> maybe I'm a PITA but that's mostly because I want to understand so that I can maintain it afterwards (ie answer questions, etc)
16:39 <cjd> That's valid
16:41 <cjd> The only thing I would suggest (and feel free to trash it if you like) is that it's important not to get trapped in comment typos and variable naming as much as the big stuff like promiscuous globals...
16:42 <vmassol> ideally yes, although variable naming can be important. Reviewing design is several order of magnitude more complex so that's why there's more comment on the small things. I understand though
16:43 <vmassol> globally that reminds me Freakonomics
16:43 <vmassol> have you read that book?
16:43 <vmassol> they mention about the new work metro
16:43 <vmassol> and the fact that there's violence and it's dirty, etc
16:44 <Slashman> has joined #xwiki
16:44 <vmassol> and the study shows that if you let a few people get away with tagging the walls and deteriorating stuff
16:44 <vmassol> very quickly everyone does it
16:44 <vmassol> and insecurity increases
16:45 <vmassol> I feel it's a bit the same about a code base
16:45 <vmassol> and when you have stuff like the oldcore then nobody wants to work on it anymore…
16:46 <vmassol> when stuff are inconsistent, hack over hack, no doc, bad var naming
16:46 <vmassol> then you get a bad feeling
16:46 <vmassol> and then
16:46 <vmassol> either you don't want to touch that code
16:46 <vmassol> or when you have to do it, you keep doing the same thing as what is there already and you even increase the technical debt
16:47 <vmassol> because it's alreadhy "dirty" so making it a little bit more dirty seems ok
16:48 <vmassol> when you have clean code you want to continue keeping it clean and you have remorse if you don't ;)
16:49 <vmassol> don't you agree?
16:50 <vmassol> said differently, I'm a believer that small things matter and can have big effects. Now we need to not piss off the contributors/committers....
16:50 <vmassol> :)
16:51 <vmassol> that's the hard part...
16:53 <tmortagne> has quit
16:53 <cjd> sorry I was just away for a moment
16:54 <cjd> ahh the "broken windows" theory
16:54 <cjd> indeed things getting chaotic is a bad thing
16:55 <cjd> Actually I think the problem with oldcore is more because of difficulty to validate and test, and fear of breaking backward compat
16:55 <cjd> build performance comes in here ;)
16:55 <vmassol> it's more missing tests
16:56 <vmassol> but you can't add tests easily because of the design
16:56 <cjd> difficulty to validate is missing tests
16:56 <cjd> and difficulty to test is ... yeah
16:56 <vmassol> but when you read the code you also get a lot of WTF moments…
16:57 <cjd> That happens when I read any code :|
16:57 <vmassol> like XWiki.getFlash()
16:57 <vmassol> ;)
16:59 <cjd> yeah, getFlash is cutting across boundries between view and controller
17:00 <vmassol> and there's no flash.vm AFAIK ...
17:00 <cjd> /nod
17:00 <cjd> so one problem is that we don't have a clear vision of what is actually being used and what is just sitting there
17:00 <cjd> if we did, we could clean things up significantly be summarily yanking anything which is in a "doesn't work, noone uses it, may never have worked" state
17:01 <vmassol> for this method actually we should move it to legacy
17:01 <cjd> but that takes courage which takes a fast build/test cycle :)
17:01 <cjd> and lots of tests
17:02 <vmassol> a quick grep shows it's not used anywhere, will move now actually! :)
17:03 <cjd> One night I was thinking about what I would do if suddenly I had to do your job. The first answer that came to my mind was "work nights for a long time" ;)
17:04 <cjd> many many scripts running over the codebase looking for things which can be fixed
17:04 <vmassol> yeah it might be a good idea to switch jobs actually, as you get blunted over time
17:04 <cjd> bring hellfire upon the build time
17:05 <vmassol> every few weeks I ask myself whether I'm doing a good job or not
17:05 <cjd> oh hell, don't start going there
17:05 <vmassol> and I have ups and downs…
17:05 <cjd> you're good
17:05 <vmassol> actually I'm not sure
17:05 <vmassol> it's been 7 years for me
17:05 <vmassol> and I was not able to do half of what I wanted to do
17:06 <cjd> :(
17:06 <vmassol> and xwiki is still not yet known worldwide… :)
17:06 <ClemensR> has joined #xwiki
17:06 <cjd> we'll get there on the second part
17:06 <cjd> first part, all I have to say is feed that inner anger at how much everything sucks
17:07 <cjd> because everything in the world is really not that great, not just software either
17:07 <cjd> guys building libraries don't know your pain when you use them, people building the tools don't know it either
17:08 <cjd> Remember yesterday you were talking about reinventing everything and I said "there has to be a limit"?
17:09 <cjd> I thought about that and I was wrong. There should be no limit at all. Do one thing at a time, start with the low hanging fruit, and there's no good reason why making *everything* better is not valid.
17:09 <vmassol> yup and I think as you get older your past experience pushes that limit down and to make some dent in the world you prefer focusing on more narrow things because you're more likely to succeed
17:10 <vmassol> now if you're in pure research then of course you have a lot more liberty
17:10 <vmassol> than you have if you need to support a user base....
17:11 <cjd> And cjdns is a unique thing because it has almost no backward compat to support so I can sneak off with some horrific tricks
17:11 <cjd> XWiki is a different story alltogether
17:11 <vmassol> that's the pain of getting old… you're getting too realistic :)
17:11 <vmassol> I love this quote:
17:11 <cjd> but not a challenge we can't beat
17:11 <vmassol> (translated from french)
17:12 <cjd> :)
17:12 <vmassol> "they didn't know it was impossible and thus they did it"
17:12 <cjd> ahh
17:13 <cjd> Those who say it can't be done should get out of the way of those who are doing it.
17:13 <cjd> --Joel Arthur Barker
17:13 <cjd> Lot of truth to those words
17:14 <vmassol> yes it's a nice quote, all is about the context and the goal…
17:14 <cjd> On my side, I do things which nobody thought of, stuff like planting the websocket directly into XWiki instead of waiting for tomcat to come along with a version which supports it
17:14 <kaisen> has quit
17:15 <cjd> and I pay my share because I have to debug my code more
17:15 <cjd> but I get it all back in the end because once I've debugged it, it's clean and I don't usually end up dealing with uglyness because someone decided to use glassfish...
17:16 <cjd> but it requires courage because when I screw up and try to do something that can't be done and it actually can't be done, I fall on my face
17:16 <vmassol> it's like our wysiwyg
17:16 <vmassol> it was nice to reimplment it initially because it brought us an edge over others at the time
17:17 <vmassol> but since it's not our core business we don't invest in it and thus we loose ground over time
17:17 <vmassol> and then it becomes a burden becuase others are overcaught you
17:17 <vmassol> and you need to pay again for removing it
17:17 <vmassol> so you better profit from the initial advantage you had or it's not worth it
17:17 <cjd> +1 that
17:17 <cjd> so we switch to a generic editor and sell the fact that XWiki is the Realtime Wiki :D
17:18 <vmassol> :)
17:18 <cjd> btw I have a couple of silly bugs to fix and then WDYT of realtime-wiki on xwiki.org?
17:19 <vmassol> if you think it's ready enough then it would be great
17:19 <vmassol> maybe on myxwiki.org first though
17:19 <vmassol> since myxwiki.org is our rea world test platform
17:19 <cjd> I think it's ready for anything
17:19 <vmassol> and then if it works fine, we can have it on xwiki.org
17:20 <cjd> all of the bugs I've discovered have been "haha I didn't think of that", nothing core level or algorithmic
17:20 <cjd> that sounds like a logical approach
17:20 <cjd> oh I really wanna do chat :D
17:21 <vmassol> wdym?
17:21 <vmassol> chat in the wiki?
17:21 <cjd> userlink -> "this user is online, chat?"
17:21 <mflorea> has quit
17:21 <vmassol> ah like fabio's extension?
17:21 <cjd> yes
17:21 <vmassol> http://extensions.xwiki.org/xwiki/bin/view/Extension/XMPP+Chat+Application
17:21 <vmassol> ?
17:21 <cjd> except since I have a well tested websocket which is capable of doing arbitrary backends, this time it will be easy
17:22 <cjd> if realtime wiki works, chat is "free"
17:22 <vmassol> cool
17:22 <cjd> video chat is not that interesting to me atm
17:22 <vmassol> sure I agree
17:22 <cjd> ideally we train people to chat in text and then enable logging so it can be searched
17:23 <cjd> [ ] Off The Record (unchecked by default so everything is logged)
17:25 <cjd> also we're going to wipe the floor with the competition when we have pervasive realtime/websocket stuff because all of the other stuff *cough* jira is basically like a struts app with some js sugar
17:25 <vmassol> :)
17:25 <cjd> like the recent changes don't auto-update, wat is this?!
17:26 <vmassol> yes that would be nice but we need to rewrite the AS first
17:27 <cjd> can we fire events and then just listen for them?
17:27 <vmassol> that's what the AS does
17:27 <vmassol> it listens to all events
17:27 <vmassol> and displays them
17:27 <cjd> ahh ok then all we need to do is listen to events and bcast them down the websocket
17:27 <cjd> even allow the client to listen for events in js using a WebSocketHandler
17:28 <vmassol> sure what I mean is that are lots of issues with the AS, first being performances
17:28 <cjd> /nod
17:28 <vmassol> so we need to rewrite it anyway
17:28 <vmassol> so if you improve it now then when we rewrite you have to rewrite more
17:28 <vmassol> I've been trying to try to fit thre rewrite in the roadmap several times already
17:28 <cjd> ahh everything would be so much easier if we just shoehored nodejs into a .jar file and tricked the customers into thinking it's struts
17:28 <vmassol> almost succeedd twice
17:28 <vmassol> ...
17:29 <vmassol> I'll continue trying and in the end I'll prevail… ;)
17:29 <cjd> careful of the bulldozer approach
17:30 <cjd> don't want you to burn out, you're our General
17:30 <vmassol> yeah that's a possibility on the long run...
17:31 <cjd> bulldozer or sneeky.js ?
17:31 <vmassol> wearing out
17:31 <cjd> I'm not gonna let you :P
17:32 <vmassol> :)
17:33 <vmassol> [friday fun] http://t.co/SQmFJIgUdA
17:33 <cjd> I was thinking, we should probably find the best technology (not the most fastionable) and use that, then we should wrap that technology in whatever our customers want
17:34 <cjd> haha
17:36 <vmassol> ‘Write clear, precise code. Every ten years it will run 1,000 times faster.’—Joe Armstrong
17:37 <cjd> write the cheapest code to develop and maintain until it's out of date
17:37 <cjd> cheap to develop implies a higher maintanence cost so it's a balance
17:37 <cjd> but in the end, everything is a prototype
17:41 <cjd> also play with nodejs, I'm to the point now of being willing to bet money that in 10 years it's going to beat everything else, it's also a lot of fun :)
17:42 <vmassol> the problem is that you're just thinking about node.js but you're not thinking about tools/educating developers/ability to recruit devleopers who know the technology/etc
17:43 <vmassol> you really need to factor all this in
17:43 <cjd> +1 that
17:43 <vmassol> at XWiki SAS for ex we have python code
17:43 <cjd> I'm just saying fool around with it :)
17:43 <vmassol> and nobody is touhcing it because nobody knows it
17:43 <vmassol> and it's decaying
17:44 <vmassol> fooling around is ok
17:44 <vmassol> :)
17:44 <cjd> I volunteered to help look at it even though I'm not a python expert
17:44 <cjd> I like a challenge
17:44 <vmassol> cool
17:44 <cjd> they said it's ok so I didn't persue it
17:44 <cjd> the problem I saw was threading, threads make everything harder to reason with
17:45 <cjd> (with the python thingy)
18:04 <mflorea> has joined #xwiki
18:20 <ClemensR> has left #xwiki
19:04 <mflorea> has quit
19:09 <vmassol> Lyes: missing @Component and @Singleton, adding now
19:15 <cjd> has quit
19:19 <lucaa> has quit
19:19 <woshilapin> has quit
19:19 <vmassol> Lyes: ok I'm done with a first quick review :)
19:20 <vmassol> a few things to fix...
19:20 <vmassol> :)
19:20 <Lyes> i check your comments
19:25 <Slashman> has quit
19:37 <lucaa> has joined #xwiki
19:37 <abusenius> has joined #xwiki
19:41 <vmassol> cjd
19:41 <vmassol> not here....
19:48 <silverdrop> has quit
19:49 <abusenius> has quit
19:53 <silverdrop> has joined #xwiki
20:06 <ramkamx> has quit
20:33 <vmassol> has quit
20:40 <vmassol> has joined #xwiki
20:53 <silverdrop> has quit
20:59 <abusenius> has joined #xwiki
21:14 <silverdrop> has joined #xwiki
21:23 <silverdrop> has quit
21:34 <lucaa> has quit
22:26 <tekzilla> has quit
22:34 <tekzilla> has joined #xwiki
23:01 <vmassol> has quit
23:50 <vmassol> has joined #xwiki
23:59 <vmassol> has quit
