IRC Archive for channel #xwiki on 10 June 2014
Last modified by Vincent Massol on 2014/06/10 23:51
<Lyes> has quit
00:20 <Lyes> has joined #xwiki
00:34 <Slashman> has quit
00:43 <abusenius> has quit
00:55 <lucaa> has quit
01:06 <Lyes> has quit
02:54 <OSIMasson> has quit
02:56 <OSIMasson> has joined #xwiki
03:09 <OSIMasson> has quit
05:44 <teekay> has joined #xwiki
06:01 <teekay> hey guys, does anyone know of an easy way to reference the spinner.gif when I have an ajax request running?
06:52 <mflorea> has joined #xwiki
07:51 <vmassol> has joined #xwiki
07:54 <teekay> hey guys, does anyone know of an easy way to reference the spinner.gif when I have an ajax request running?
08:17 <mflorea> has quit
08:20 <kaisen> has joined #xwiki
08:37 <msmeria> has joined #xwiki
08:40 <kaisen> Hello, new week new luck. I have the problem that I cannot start the Syntax Help Page. I get the following velocity error message and I don't have an idea where to look at. Can someone have a look at it? http://mysticpaste.com/view/z6rrmr8o91?2
08:53 <KermitTheFragger> has joined #xwiki
09:02 <gdelhumeau> has joined #xwiki
09:07 <teekay> has quit
09:12 <mflorea> has joined #xwiki
09:13 <vmassol> kaisen: good morning
09:13 <vmassol> WDYM by "start the Syntax Help Page"?
09:18 <evalica> has joined #xwiki
09:19 <woshilapin> has joined #xwiki
09:27 <D-Spair> has quit
09:30 <vmassol> lots of spam accounts it seems…
09:30 <ClemensR> has joined #xwiki
09:31 <Denis1> has joined #xwiki
09:31 <Denis1> is now known as <Denis>
09:34 <Lyes> has joined #xwiki
09:36 <mflorea> has quit
09:57 <mflorea> has joined #xwiki
10:01 <lucaa> has joined #xwiki
10:15 <kaisen> Hello, I have one more question. Is there an manual how to configure the solor search page that it acts like the top right search?
10:17 <vmassol> kaisen: is it 1) that you prefer to the top right search results or 2) that you'd like to have the same results for both searches?
10:18 <kaisen> 1. I want search suggestings under the search field 2) the same results :)
10:19 <vmassol> mflorea: some interesting input for you :)
10:19 <vmassol> it's not the first time I hear users who'd like the same results for both searches
10:19 <vmassol> (and are puzzled when they don't get the same result)
10:19 <vmassol> s/for you/for us ;)
10:20 <vmassol> I don't know what are our options though
10:20 <tmortagne> has joined #xwiki
10:21 <mflorea> they are two different things for me. I don't have a solution either.
10:21 <D-Spair> has joined #xwiki
10:23 <kaisen> My Problem is that if someone enter a search work on the top and didn't type it fully out and press enter, the other search doesn't show anything until he write the full word or add a *
10:25 <mflorea> last time I checked google wasn't performing prefix matching, if you search for "hou" you won't get results for "house".
10:25 <mflorea> search suggest is one thing, and full text search is another thing
10:25 <kaisen> yes your right
10:26 <mflorea> what we miss is giving the user suggestion for search keywords
10:26 <kaisen> But on the top search it is like a * is add as soon as I have 3 character, on the other search I need to do it manually
10:26 <mflorea> so when you type "hou", we suggest you to search for "house", as google does
10:27 <kaisen> Yes this would be also a nice feature
10:27 <mflorea> yes, the top right search adds it (note that in the latest version this doesn't happen by default anymore, but we're going to get back to the original behavior most probably)
10:28 <kaisen> I use 6.0.1 and it seems to working for me
10:29 <mflorea> hmm, did you upgrade to 6.0.1 or is it a new install
10:29 <kaisen> upgrade
10:29 <kaisen> but my wiki seems to have anyway several problems :(
10:30 <mflorea> ok, that explains it, you must have the old search suggest sources, that still add the *.
10:30 <mflorea> anyway, we'll put back the * soon
10:30 <kaisen> Ok in this case I don't care :)
10:33 <kaisen> But is there a chance to show the search suggest also on the normale solor search?
10:36 <Denis1> has joined #xwiki
10:36 <Denis> has quit
10:36 <Denis1> has quit
10:36 <Denis> has joined #xwiki
10:36 <kaisen> Beacuse if you search in the top you get also shown attachments, but if you have enough other search results the go under in the results
10:41 <Denis1> has joined #xwiki
10:44 <Denis> has quit
10:57 <Slashman> has joined #xwiki
11:06 <kaisen> Ok I see were my problem "comes from". The filter which are set as default. If I want attachements I need to deactivate documents and activate attachemnts. Is there a way that documents and attachements are show as default?
11:17 <ClemensR> kaisen: I think there is something to set in the Main.SolrSearchConfig ... checking
11:19 <vmassol> guys, I'd like your quick input on which API you prefer for the script user (this is for the new mail sender), see https://gist.githubusercontent.com/vmassol/f525b95644c6fd45b79b/raw/3ed770192f4c8afad4d743d1ba2570dd455e0ff0/gistfile1.txt
11:19 <vmassol> https://gist.githubusercontent.com/vmassol/f525b95644c6fd45b79b/raw/d6950d5877c18c28deb5e6718088a53f9f7faf97/gistfile1.txt
11:23 <ClemensR> I guess in variation 2 one does not need to pass in the message in $message,send($message) ;)
11:23 <tmortagne> same question than ClemensR
11:23 <tmortagne> and the line above too
11:23 <tmortagne> I don't really see why it's passing the $message
11:23 <vmassol> ah yes copy paste ;)
11:23 <tmortagne> without the $message in parameter I prefer the variation 2
11:24 <vmassol> ClemensR: any preference?
11:25 <ClemensR> if not exposing the XWikiMimeMessage in Variant 1 it would mean the service accepts an object-valued parameter and hat to check nobody passed in junk there, right ?
11:25 <vmassol> variant1 exposes XWikiMimeMessage which becomes a class just for the scripting api
11:25 <ClemensR> if I have to use the interface I would prefer Variant 2 anyway
11:25 <vmassol> oops
11:25 <vmassol> sorry
11:25 <vmassol> I meant var 2
11:26 <vmassol> in var 1, the api takes a MimeMessage param
11:26 <tmortagne> people will try to use $message in variant 1 too I think anyway and modifying will break scripts
11:26 <vmassol> my pref also goes for var 2 which is more natural … even though it forces a bigger difference between the java api and the scripting api
11:26 <vmassol> ok let's do var2
11:26 <tmortagne> that could also be the Java API
11:27 <vmassol> not nice for the java api
11:27 <vmassol> btw see http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
11:28 <tmortagne> in Java too it's nicer to directly manipulate an object than having to pass it to tons of APIs
11:28 <vmassol> I much prefer to decouple and let java mail be exposed as much as possbile
11:28 <vmassol> now
11:28 <vmassol> we can think about some shortcut api if we want but that's a different topic
11:28 <tmortagne> just thinking that if we have to define an API anyway for the script we can use it in Java too
11:29 <vmassol> yes I know I've had the same thoughts already
11:29 <tmortagne> yes it can be a shortcut/helper
11:30 <tmortagne> exposing java mail is very nice, but it does not prevent us from also providing some helpers
11:30 <vmassol> yes, and we already do, for exemple MailSender is a shortcut, we still allow sending with pure javamail but this ones add some logic to handle non blocking mail sending + scheduler
11:31 <vmassol> but yes after we've done the first version we'll need to decide if we want a larger helper
11:31 <vmassol> that creates the session internally, etc like the scirpting api does
11:33 <ClemensR> kaisen: I think if you edit Main.SolrSearchConfig in the wiki editor, you can look for 'facetQuery' and change 'type':'DOCUMENT' to 'type': ['DOCUMENT','ATTACHMENT'] .... that works for me. I hope it is a supported use case ;)
11:41 <kaisen> @ ClemensR thanks. I missed the [ ] which end up in macro error :)
11:42 <ClemensR> ah, ok, yes, thats a bit tricky there
11:47 <kaisen> Maybe this should be standard that there is no filter set as it is confusing if you don't get all results
11:47 <kaisen> but if you get to much you can start to set filtres
12:09 <vmassol1> has joined #xwiki
12:10 <vmassol> has quit
12:16 <ClemensR> has left #xwiki
12:24 <tmortagne> anyone knows a Java lib providing API to do hierarchical locking ? (or maybe something I did not saw in Java 7)
12:25 <vmassol1> locking for what?
12:25 <vmassol1> is now known as <vmassol>
12:26 <vmassol> oh you mean concurrency and semaphores?
12:26 <vmassol> you mean this domain: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/package-summary.html ?
12:27 <tmortagne> vmassol: no I don't mean concurrency and semaphore, I know this package
12:28 <tmortagne> I mean handling hierarchical locking in a tree, dealing with which nod should be locked when
12:30 <tmortagne> s/nod/node/
12:49 <lucaa> has quit
13:02 <vmassol> you want a concurrent tree (http://stackoverflow.com/questions/11189784/efficient-concurrent-tree) ?
13:52 <lucaa> has joined #xwiki
14:03 <ClemensR> has joined #xwiki
14:15 <D-Spair> has quit
14:21 <tmortagne> vmassol: I'm not searching for a concurrent tree, I want something to handle locking for tasks that are going to modify stuff not in memory but thing that are organized in a tree. An example (which is not my use case but easy to understand) is having a object to manager access to a filesystem from various thread where you would want to modify sibling at the same time but where modification on a file should lock any of it's parent folder and the op
14:22 <tmortagne> s/it's/its/
14:22 <tmortagne> (which is called hierarchical locking)
14:29 <vmassol> otp
14:52 <lucaa> has quit
15:09 <lucaa> has joined #xwiki
15:41 <grimeton> has quit
15:42 <grimeton> has joined #xwiki
16:06 <cjd> has joined #xwiki
16:11 <evalica> has quit
16:26 <msmeria> has quit
16:35 <tmortagne> has quit
16:50 <cjd> hi vmassol, what's up?
16:50 <Denis1> is now known as <Denis>
16:50 <vmassol> hi caleb
16:50 <vmassol> working on mail api with Lyes
16:50 <cjd> yeah, did you have a problem with .fsattach.config ?
16:50 <vmassol> btw cjd did you see my comment on github about the property naming
16:50 <vmassol> ?
16:50 <vmassol> yes I commented
16:51 <vmassol> on your commit
16:51 <cjd> just getting back to work, I spent the entire day at prefecture de police
16:51 <vmassol> ouch not nice
16:51 <vmassol> I referenced my comment in the jira issue too
16:52 <cjd> idk I think fsattach is "nicer" because there is no generic filesystem module of which attachments is a submodule
16:52 <cjd> but I really don't care what color the bike shed is
16:52 <vmassol> then I don't understand your maven module
16:52 <cjd> if it gets the bug fixed and ships to users I'm happy, as fast as that can happen is what makes me happiest :)
16:53 <vmassol> could you explain why you have these 2 modules side by side:
16:53 <vmassol> - xwiki-platform-store-filesystem
16:53 <vmassol> - xwiki-platform-store-filesystem-attachments
16:53 <vmassol> and why the later one is not a child of the former
16:54 <cjd> I can't remember
16:54 <vmassol> usually "-" are separator for child/ancestor
16:55 <vmassol> so what you are saying is that they have no relationship of parent/child
16:55 <cjd> filesystem looks like some generic tools for making fs access easier
16:56 <cjd> ./xwiki-platform-store-filesystem/src/main/java/org/xwiki/store/FileSaveTransactionRunnable.java <-- that's a 2 stage commit file saver which will revert if for some reason the db fails to commit related metadata
16:57 <vmassol> ok the store module looks a bit like a mess :)
16:57 <vmassol> there's a notion of filesystem but there's no notion of RDBMS
16:57 <vmassol> that's really strange
16:57 <cjd> not at all
16:58 <vmassol> it should be there in the hierarchy
16:58 <cjd> I didn't need to store anything in RDBMS so why would I write it?
16:58 <vmassol> we don't store documents in the DB???
16:58 <vmassol> (or attachments)
16:58 <cjd> that's done in oldcore :)
16:59 <vmassol> oldcore is not future
16:59 <vmassol> so we need to make way for the new apis
16:59 <vmassol> so you acknowledge that
16:59 <vmassol> there are 2 types of store ATM
16:59 <vmassol> 1) DB
16:59 <vmassol> 2) FS
17:00 <vmassol> so it makes sense to have store.filesystem.something to make way for store.database.something
17:00 <vmassol> no?
17:00 <vmassol> what you implemented is only for the FS AFAIK
17:00 <vmassol> and you only implemented storing attachments on the FS
17:00 <cjd> mhm
17:01 <vmassol> but shouldn't we allow in some future to also store documents on the FS as an option?
17:01 <vmassol> (or to some other storage)
17:01 <cjd> no idea, hard to know if it would be useful
17:02 <vmassol> I thought you were implementing the filesystem attachment store
17:02 <cjd> not really, it's done
17:02 <vmassol> personally I'd have written: store.attachment.filesystem but you seems to have done instead: store.filesystem.attachment
17:03 <tmortagne> has joined #xwiki
17:03 <vmassol> so you wrote the attachment filesystem store
17:03 <cjd> no, I did store.fsattach.
17:03 <vmassol> that's a property name, not a module
17:03 <cjd> oh right
17:03 <vmassol> the point is finding the property name based on the module
17:03 <cjd> modules can be shuffled around later if needed
17:03 <vmassol> as I've pointed out we have a very simple rule
17:04 <vmassol> for naming properties
17:04 <vmassol> (in the comment)
17:04 <vmassol> it seems the hard part is agreeing that the module for which you wish a property is the Filesystem attachment store
17:04 <vmassol> *property for
17:04 <vmassol> ie 3 concepts:
17:04 <vmassol> - store
17:04 <vmassol> - attachment
17:05 <vmassol> - filesystem
17:05 <cjd> I think you're bikeshedding
17:05 <vmassol> for some reason I don't understand you seem to think there's only 2 concepts
17:05 <vmassol> - store
17:05 <vmassol> - fsattach
17:05 <vmassol> which could work
17:05 <vmassol> it's just not very scalable and different from everything else we do
17:06 <vmassol> so when we implement doc in DB we would have: dbdoc
17:06 <vmassol> store.fsattach, store.dbdoc, store.dbattach, etc
17:06 <vmassol> it's a flater namespace
17:06 <vmassol> googling bikeshedding :)
17:07 <cjd> one sec
17:07 <vmassol> ok nice word
17:07 <vmassol> I'll remember it
17:07 <vmassol> :)
17:07 <vmassol> learnt something today!
17:07 <vmassol> yes, 99% of api work is about bikeshedding
17:07 <cjd> http://bikeshed.com/
17:07 <cjd> it's worth a read
17:08 <vmassol> will do but I get the concept
17:08 <cjd> because these kinds of api discussions did a horrific job on the freebsd community
17:08 <vmassol> the problem is when you don't do anything instead of acting
17:08 <cjd> IMO pick something, stick with it enough that a casual user can't spot inconsistancy and ship ship ship :)
17:08 <vmassol> but thinking a bit is not counterproductive IMO
17:09 <vmassol> it must not last too long
17:09 <cjd> in 10 minutes it will have lasted as long as it took to write the patch
17:10 <vmassol> that's not much compared to the cost we will hav eto pay to change the name
17:10 <cjd> a config variable == you don't change it
17:10 <cjd> but if all fsattach is fsattach, store.rdbms is not *obviously* inconsistant
17:12 <vmassol> it wouldn' tbe rdbms, it would be store.rdbmsattach :)
17:12 <cjd> not if we don't do it that way
17:12 <cjd> my point is the users will not notice if we have store.rdbms.someValue
17:12 <cjd> and then on the other side we have store.fsattach.someConfig
17:13 <cjd> nobody is going to notice a thing
17:13 <vmassol> especially since the store module will probably have to go away or be heavily refactored
17:13 <vmassol> since it wasn't coded with the goal of being a replacement to the existing store
17:14 <vmassol> so when we rewrite the existing store, the api will probably be different to take into account all store options
17:14 <vmassol> ok so
17:15 <vmassol> if nobody disagrees with fsattach, we'll keep it and I'll go with the flow, hoping that you'll still be around if we need to change it ;)
17:15 <vmassol> btw this reminds me of a comment from ludovic
17:16 <vmassol> that he would like us to join xwiki.properties and xwiki.cfg
17:16 <cjd> I'd be favorable to that
17:16 <vmassol> because it's too complex for users to have to look at 2 config files
17:16 <cjd> +1
17:16 <vmassol> and now the store config is split in 2 places
17:17 <cjd> Something I've noticed about windows kernel is it's incredibly stupendously well engineered
17:17 <vmassol> so far we tried to have domains defined in either of the 2 files but not in both
17:17 <cjd> designed by people smarter than me, the entire kernel is asynchronous which makes it like the only kernel in the world like that
17:17 <cjd> but writing code to interact with it is impossible
17:18 <cjd> whereas linux is basically a mountain of hacks but they're very fast hacks and writing code for it is really easy because the things you're most likely to do are streamlined
17:18 <cjd> same story with solaris, brilliant beautiful design
17:18 <cjd> takes 200 LoC to open a tun device which can be done in linux with 30
17:19 <cjd> anyway I guess my point is embrase the ugly and make stuff which is really easy to use
17:19 <cjd> :)
17:21 <vmassol> yes sure it really boils down to why you code
17:22 <vmassol> personally I consider it an art and I'm trying to achieve perfection as much as possible
17:22 <cjd> I recognize your position
17:23 <vmassol> of course it's not possible in a not perfect world...
17:23 <vmassol> :)
17:23 <cjd> Do you think I can convince you to read another piece of text when you get a chance?
17:23 <vmassol> hehe
17:24 <cjd> http://zedshaw.com/essays/master_and_expert.html <-- This had a bit of an impact on me as a programmer
17:24 <cjd> that and a lot of pressure to ship ship ship and kill the bugs (in my project)
17:25 <cjd> I guess the difference for me is now I don't really see anything as "complete" anymore.
17:25 <cjd> It's beautiful, it's a beautiful construction site
17:26 <vmassol> oh yes it's never finished I agree about that
17:51 <ClemensR> has left #xwiki
18:00 <kaisen> bye
18:01 <kaisen> has quit
18:05 <vmassol> bye
18:06 <gdelhumeau> has quit
18:06 <lucaa> has quit
18:06 <lucaa> has joined #xwiki
18:08 <vmassol> hey guyes
18:08 <vmassol> just noticed that yesterday was supposed to be the 6.1M2 release :)
18:08 <vmassol> who's the RM already?
18:09 <vmassol> s/guyes/guys
18:13 <vmassol> tmortagne, mflorea: do you remember?
18:15 <woshilapin> has quit
18:16 <mflorea> vmassol: remember what?
18:16 <vmassol> who's the RM for 6.1M2
18:16 <vmassol> (see above)
18:16 <mflorea> see above, (18:08:54) xwikibot: dev:ReleasePlans.ReleasePlan61M2 was created by xwiki:XWiki.mflorea - http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan61M2
18:17 <mflorea> I'll try to release tomorrow
18:17 <vmassol> hmm I dont have this message, strange
18:17 <mflorea> I have to go now
18:17 <vmassol> mflorea: all committers are good?
18:17 <vmassol> ok
18:18 <mflorea> on my side, I have a few small issues that I didn't had time to commit because I worked on File Manager, but nothing critical for 6.1M2
18:19 <vmassol> ok
18:19 <mflorea> has quit
18:19 <vmassol> on my side it should be ok too, I have lots of stuff with @since 6.1M2 but I can change them for RC1 I guess
18:23 <cjd> thx for the catch
18:27 <KermitTheFragger> has quit
18:42 <abusenius> has joined #xwiki
19:13 <tmortagne> has quit
19:28 <Slashman> has quit
19:30 <cjd> has quit
19:39 <vmassol> Lyes: I've added a very first version of the script service implementation. I need to figure out what's the best strategy for testing it now. After you commit the default mime body part factory for String we should have all the pieces to start making the integration test pass :)
19:42 <Lyes> cool, I'll see it
20:04 <webczat> has joined #xwiki
20:04 <webczat> Hello, can all users in xwiki default install modify ui pages in the main space or spaces other than XWiki?
20:05 <vmassol> depends on the space
20:05 <vmassol> for the Main space yes, the default permission allows editing those pages
20:05 <vmassol> but you can set the permission you wish
20:06 <webczat> I meant for example space blog, annotation code etc
20:07 <vmassol> depends
20:07 <vmassol> why?
20:07 <webczat> I know that XWiki is not editable
20:07 <vmassol> you can set the permission you wish on a space
20:08 <vmassol> for ex the Scheduler space is only editable by admins
20:08 <webczat> I've removed all right objects from the wiki to start from default permissions, but I know that default is view, edit, comment/etc for XWikiAllGroup so just excluding guests. I tried to edit Blog/Management as a guest after removing perms and it was allowed
20:09 <webczat> I didn't touch the blog space, just global perms
20:09 <vmassol> if you remove the default permissions then there's no more any default :)
20:09 <webczat> And because all users are added to XWikiAllGroup then...
20:10 <vmassol> I still don't understand what's your problem/question :)
20:10 <vmassol> you want to know how to set up permissions?
20:10 <webczat> Withput any permissions, all users can view, edit and comment, I didn't touch specific spaces. but defaults for the wiki when I don't touch them is probably view, edit and comment for the wiki to XWikiAllGroup.
20:10 <vmassol> there's no such thing as "default permission", the permissions are defined by the rights objects
20:11 <vmassol> try starting your wiki with an empty DB for ex
20:12 <webczat> I know that a new wiki does not have any rights set. guests can view, edit and comment there, can't they?
20:12 <vmassol> actually I don't remember, this may have changed now, let me give you the link to the doc on this
20:13 <vmassol> http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module
20:14 <webczat> I've actually read the docs, I should maybe reread this one again. What I'm actually asking about is a different thing: is it normal that any user having global edit can edit pages like Blog/Management? I could do it as a guest when permissions were changed to all none for him, and defaults for XWikiAllGroup after installing the ui is allow edit.
20:14 <vmassol> when no rights are set any user of the wiki (registered or not) used to be able to do anything (view, edit, admin pr, etc
20:15 <vmassol> now Denis has modified the implementation and I don't remember if that's still the case or not
20:16 <vmassol> webczat: Blog.Management checks for admin right
20:16 <vmassol> you can edit it
20:16 <webczat> It is what I'm asking. Can users do such things by default? I am changing my group layout slightly so I cannot currently check unless using a guest user.
20:17 <vmassol> #if($hasAdmin)
20:17 <vmassol> now
20:17 <webczat> Blog/Management checks for admin right when it is used. but not when it is edited I believe
20:17 <vmassol> I do agree that this page is wrong IMO
20:17 <vmassol> it should have a permission set on it
20:18 <vmassol> since the blog space is not protected
20:18 <vmassol> anyone with edit right could change that page and remove the test
20:18 <vmassol> hmm wait
20:18 <webczat> I tried once from guest. I didn't change anything but I was allowed to save.
20:19 <vmassol> it probably does some checks later on
20:19 <vmassol> for admin
20:19 <vmassol> so you're probably safe
20:19 <vmassol> in any case
20:19 <vmassol> if it calls unrpoetcted api any user with edit rights could also call them :)
20:19 <vmassol> so it's ok
20:20 <webczat> But any user with edit could ctrl+a and del the page :D
20:20 <vmassol> sure
20:20 <webczat> I know, I can change permissions
20:20 <vmassol> but thaty's not a security risk
20:20 <vmassol> any user with edit right can do that on any page he can edit
20:20 <webczat> I can even reimport
20:20 <vmassol> import requires admin perm
20:20 <webczat> and this one is not editable by default
20:21 <webczat> but checking other things. No blog/ page is protected in any way
20:21 <webczat> I believe so at least
20:21 <vmassol> sure that's voluntary
20:21 <vmassol> what's the problem?
20:22 <webczat> I'm just not sure what is and is not protected, like annotation code probably isn't although I'm just trying to read xml
20:23 <vmassol> ok said differenty no page needs to be protected
20:23 <vmassol> because all permissions checks are done at the java level
20:23 <vmassol> so users can only do not dangerous things
20:24 <vmassol> sorry I have to go, dinner time here!
20:24 <vmassol> gl
20:25 <webczat> what about protected api and issues?
21:14 <lucaa> has quit
21:26 <Denis> has quit
22:33 <sburjan> has quit
22:33 <sburjan> has joined #xwiki
22:54 <tekzilla> has quit
22:56 <lucaa> has joined #xwiki
23:11 <tekzilla> has joined #xwiki
23:51 <vmassol> has quit
00:20 <Lyes> has joined #xwiki
00:34 <Slashman> has quit
00:43 <abusenius> has quit
00:55 <lucaa> has quit
01:06 <Lyes> has quit
02:54 <OSIMasson> has quit
02:56 <OSIMasson> has joined #xwiki
03:09 <OSIMasson> has quit
05:44 <teekay> has joined #xwiki
06:01 <teekay> hey guys, does anyone know of an easy way to reference the spinner.gif when I have an ajax request running?
06:52 <mflorea> has joined #xwiki
07:51 <vmassol> has joined #xwiki
07:54 <teekay> hey guys, does anyone know of an easy way to reference the spinner.gif when I have an ajax request running?
08:17 <mflorea> has quit
08:20 <kaisen> has joined #xwiki
08:37 <msmeria> has joined #xwiki
08:40 <kaisen> Hello, new week new luck. I have the problem that I cannot start the Syntax Help Page. I get the following velocity error message and I don't have an idea where to look at. Can someone have a look at it? http://mysticpaste.com/view/z6rrmr8o91?2
08:53 <KermitTheFragger> has joined #xwiki
09:02 <gdelhumeau> has joined #xwiki
09:07 <teekay> has quit
09:12 <mflorea> has joined #xwiki
09:13 <vmassol> kaisen: good morning
09:13 <vmassol> WDYM by "start the Syntax Help Page"?
09:18 <evalica> has joined #xwiki
09:19 <woshilapin> has joined #xwiki
09:27 <D-Spair> has quit
09:30 <vmassol> lots of spam accounts it seems…
09:30 <ClemensR> has joined #xwiki
09:31 <Denis1> has joined #xwiki
09:31 <Denis1> is now known as <Denis>
09:34 <Lyes> has joined #xwiki
09:36 <mflorea> has quit
09:57 <mflorea> has joined #xwiki
10:01 <lucaa> has joined #xwiki
10:15 <kaisen> Hello, I have one more question. Is there an manual how to configure the solor search page that it acts like the top right search?
10:17 <vmassol> kaisen: is it 1) that you prefer to the top right search results or 2) that you'd like to have the same results for both searches?
10:18 <kaisen> 1. I want search suggestings under the search field 2) the same results :)
10:19 <vmassol> mflorea: some interesting input for you :)
10:19 <vmassol> it's not the first time I hear users who'd like the same results for both searches
10:19 <vmassol> (and are puzzled when they don't get the same result)
10:19 <vmassol> s/for you/for us ;)
10:20 <vmassol> I don't know what are our options though
10:20 <tmortagne> has joined #xwiki
10:21 <mflorea> they are two different things for me. I don't have a solution either.
10:21 <D-Spair> has joined #xwiki
10:23 <kaisen> My Problem is that if someone enter a search work on the top and didn't type it fully out and press enter, the other search doesn't show anything until he write the full word or add a *
10:25 <mflorea> last time I checked google wasn't performing prefix matching, if you search for "hou" you won't get results for "house".
10:25 <mflorea> search suggest is one thing, and full text search is another thing
10:25 <kaisen> yes your right
10:26 <mflorea> what we miss is giving the user suggestion for search keywords
10:26 <kaisen> But on the top search it is like a * is add as soon as I have 3 character, on the other search I need to do it manually
10:26 <mflorea> so when you type "hou", we suggest you to search for "house", as google does
10:27 <kaisen> Yes this would be also a nice feature
10:27 <mflorea> yes, the top right search adds it (note that in the latest version this doesn't happen by default anymore, but we're going to get back to the original behavior most probably)
10:28 <kaisen> I use 6.0.1 and it seems to working for me
10:29 <mflorea> hmm, did you upgrade to 6.0.1 or is it a new install
10:29 <kaisen> upgrade
10:29 <kaisen> but my wiki seems to have anyway several problems :(
10:30 <mflorea> ok, that explains it, you must have the old search suggest sources, that still add the *.
10:30 <mflorea> anyway, we'll put back the * soon
10:30 <kaisen> Ok in this case I don't care :)
10:33 <kaisen> But is there a chance to show the search suggest also on the normale solor search?
10:36 <Denis1> has joined #xwiki
10:36 <Denis> has quit
10:36 <Denis1> has quit
10:36 <Denis> has joined #xwiki
10:36 <kaisen> Beacuse if you search in the top you get also shown attachments, but if you have enough other search results the go under in the results
10:41 <Denis1> has joined #xwiki
10:44 <Denis> has quit
10:57 <Slashman> has joined #xwiki
11:06 <kaisen> Ok I see were my problem "comes from". The filter which are set as default. If I want attachements I need to deactivate documents and activate attachemnts. Is there a way that documents and attachements are show as default?
11:17 <ClemensR> kaisen: I think there is something to set in the Main.SolrSearchConfig ... checking
11:19 <vmassol> guys, I'd like your quick input on which API you prefer for the script user (this is for the new mail sender), see https://gist.githubusercontent.com/vmassol/f525b95644c6fd45b79b/raw/3ed770192f4c8afad4d743d1ba2570dd455e0ff0/gistfile1.txt
11:19 <vmassol> https://gist.githubusercontent.com/vmassol/f525b95644c6fd45b79b/raw/d6950d5877c18c28deb5e6718088a53f9f7faf97/gistfile1.txt
11:23 <ClemensR> I guess in variation 2 one does not need to pass in the message in $message,send($message) ;)
11:23 <tmortagne> same question than ClemensR
11:23 <tmortagne> and the line above too
11:23 <tmortagne> I don't really see why it's passing the $message
11:23 <vmassol> ah yes copy paste ;)
11:23 <tmortagne> without the $message in parameter I prefer the variation 2
11:24 <vmassol> ClemensR: any preference?
11:25 <ClemensR> if not exposing the XWikiMimeMessage in Variant 1 it would mean the service accepts an object-valued parameter and hat to check nobody passed in junk there, right ?
11:25 <vmassol> variant1 exposes XWikiMimeMessage which becomes a class just for the scripting api
11:25 <ClemensR> if I have to use the interface I would prefer Variant 2 anyway
11:25 <vmassol> oops
11:25 <vmassol> sorry
11:25 <vmassol> I meant var 2
11:26 <vmassol> in var 1, the api takes a MimeMessage param
11:26 <tmortagne> people will try to use $message in variant 1 too I think anyway and modifying will break scripts
11:26 <vmassol> my pref also goes for var 2 which is more natural … even though it forces a bigger difference between the java api and the scripting api
11:26 <vmassol> ok let's do var2
11:26 <tmortagne> that could also be the Java API
11:27 <vmassol> not nice for the java api
11:27 <vmassol> btw see http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
11:28 <tmortagne> in Java too it's nicer to directly manipulate an object than having to pass it to tons of APIs
11:28 <vmassol> I much prefer to decouple and let java mail be exposed as much as possbile
11:28 <vmassol> now
11:28 <vmassol> we can think about some shortcut api if we want but that's a different topic
11:28 <tmortagne> just thinking that if we have to define an API anyway for the script we can use it in Java too
11:29 <vmassol> yes I know I've had the same thoughts already
11:29 <tmortagne> yes it can be a shortcut/helper
11:30 <tmortagne> exposing java mail is very nice, but it does not prevent us from also providing some helpers
11:30 <vmassol> yes, and we already do, for exemple MailSender is a shortcut, we still allow sending with pure javamail but this ones add some logic to handle non blocking mail sending + scheduler
11:31 <vmassol> but yes after we've done the first version we'll need to decide if we want a larger helper
11:31 <vmassol> that creates the session internally, etc like the scirpting api does
11:33 <ClemensR> kaisen: I think if you edit Main.SolrSearchConfig in the wiki editor, you can look for 'facetQuery' and change 'type':'DOCUMENT' to 'type': ['DOCUMENT','ATTACHMENT'] .... that works for me. I hope it is a supported use case ;)
11:41 <kaisen> @ ClemensR thanks. I missed the [ ] which end up in macro error :)
11:42 <ClemensR> ah, ok, yes, thats a bit tricky there
11:47 <kaisen> Maybe this should be standard that there is no filter set as it is confusing if you don't get all results
11:47 <kaisen> but if you get to much you can start to set filtres
12:09 <vmassol1> has joined #xwiki
12:10 <vmassol> has quit
12:16 <ClemensR> has left #xwiki
12:24 <tmortagne> anyone knows a Java lib providing API to do hierarchical locking ? (or maybe something I did not saw in Java 7)
12:25 <vmassol1> locking for what?
12:25 <vmassol1> is now known as <vmassol>
12:26 <vmassol> oh you mean concurrency and semaphores?
12:26 <vmassol> you mean this domain: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/package-summary.html ?
12:27 <tmortagne> vmassol: no I don't mean concurrency and semaphore, I know this package
12:28 <tmortagne> I mean handling hierarchical locking in a tree, dealing with which nod should be locked when
12:30 <tmortagne> s/nod/node/
12:49 <lucaa> has quit
13:02 <vmassol> you want a concurrent tree (http://stackoverflow.com/questions/11189784/efficient-concurrent-tree) ?
13:52 <lucaa> has joined #xwiki
14:03 <ClemensR> has joined #xwiki
14:15 <D-Spair> has quit
14:21 <tmortagne> vmassol: I'm not searching for a concurrent tree, I want something to handle locking for tasks that are going to modify stuff not in memory but thing that are organized in a tree. An example (which is not my use case but easy to understand) is having a object to manager access to a filesystem from various thread where you would want to modify sibling at the same time but where modification on a file should lock any of it's parent folder and the op
14:22 <tmortagne> s/it's/its/
14:22 <tmortagne> (which is called hierarchical locking)
14:29 <vmassol> otp
14:52 <lucaa> has quit
15:09 <lucaa> has joined #xwiki
15:41 <grimeton> has quit
15:42 <grimeton> has joined #xwiki
16:06 <cjd> has joined #xwiki
16:11 <evalica> has quit
16:26 <msmeria> has quit
16:35 <tmortagne> has quit
16:50 <cjd> hi vmassol, what's up?
16:50 <Denis1> is now known as <Denis>
16:50 <vmassol> hi caleb
16:50 <vmassol> working on mail api with Lyes
16:50 <cjd> yeah, did you have a problem with .fsattach.config ?
16:50 <vmassol> btw cjd did you see my comment on github about the property naming
16:50 <vmassol> ?
16:50 <vmassol> yes I commented
16:51 <vmassol> on your commit
16:51 <cjd> just getting back to work, I spent the entire day at prefecture de police
16:51 <vmassol> ouch not nice
16:51 <vmassol> I referenced my comment in the jira issue too
16:52 <cjd> idk I think fsattach is "nicer" because there is no generic filesystem module of which attachments is a submodule
16:52 <cjd> but I really don't care what color the bike shed is
16:52 <vmassol> then I don't understand your maven module
16:52 <cjd> if it gets the bug fixed and ships to users I'm happy, as fast as that can happen is what makes me happiest :)
16:53 <vmassol> could you explain why you have these 2 modules side by side:
16:53 <vmassol> - xwiki-platform-store-filesystem
16:53 <vmassol> - xwiki-platform-store-filesystem-attachments
16:53 <vmassol> and why the later one is not a child of the former
16:54 <cjd> I can't remember
16:54 <vmassol> usually "-" are separator for child/ancestor
16:55 <vmassol> so what you are saying is that they have no relationship of parent/child
16:55 <cjd> filesystem looks like some generic tools for making fs access easier
16:56 <cjd> ./xwiki-platform-store-filesystem/src/main/java/org/xwiki/store/FileSaveTransactionRunnable.java <-- that's a 2 stage commit file saver which will revert if for some reason the db fails to commit related metadata
16:57 <vmassol> ok the store module looks a bit like a mess :)
16:57 <vmassol> there's a notion of filesystem but there's no notion of RDBMS
16:57 <vmassol> that's really strange
16:57 <cjd> not at all
16:58 <vmassol> it should be there in the hierarchy
16:58 <cjd> I didn't need to store anything in RDBMS so why would I write it?
16:58 <vmassol> we don't store documents in the DB???
16:58 <vmassol> (or attachments)
16:58 <cjd> that's done in oldcore :)
16:59 <vmassol> oldcore is not future
16:59 <vmassol> so we need to make way for the new apis
16:59 <vmassol> so you acknowledge that
16:59 <vmassol> there are 2 types of store ATM
16:59 <vmassol> 1) DB
16:59 <vmassol> 2) FS
17:00 <vmassol> so it makes sense to have store.filesystem.something to make way for store.database.something
17:00 <vmassol> no?
17:00 <vmassol> what you implemented is only for the FS AFAIK
17:00 <vmassol> and you only implemented storing attachments on the FS
17:00 <cjd> mhm
17:01 <vmassol> but shouldn't we allow in some future to also store documents on the FS as an option?
17:01 <vmassol> (or to some other storage)
17:01 <cjd> no idea, hard to know if it would be useful
17:02 <vmassol> I thought you were implementing the filesystem attachment store
17:02 <cjd> not really, it's done
17:02 <vmassol> personally I'd have written: store.attachment.filesystem but you seems to have done instead: store.filesystem.attachment
17:03 <tmortagne> has joined #xwiki
17:03 <vmassol> so you wrote the attachment filesystem store
17:03 <cjd> no, I did store.fsattach.
17:03 <vmassol> that's a property name, not a module
17:03 <cjd> oh right
17:03 <vmassol> the point is finding the property name based on the module
17:03 <cjd> modules can be shuffled around later if needed
17:03 <vmassol> as I've pointed out we have a very simple rule
17:04 <vmassol> for naming properties
17:04 <vmassol> (in the comment)
17:04 <vmassol> it seems the hard part is agreeing that the module for which you wish a property is the Filesystem attachment store
17:04 <vmassol> *property for
17:04 <vmassol> ie 3 concepts:
17:04 <vmassol> - store
17:04 <vmassol> - attachment
17:05 <vmassol> - filesystem
17:05 <cjd> I think you're bikeshedding
17:05 <vmassol> for some reason I don't understand you seem to think there's only 2 concepts
17:05 <vmassol> - store
17:05 <vmassol> - fsattach
17:05 <vmassol> which could work
17:05 <vmassol> it's just not very scalable and different from everything else we do
17:06 <vmassol> so when we implement doc in DB we would have: dbdoc
17:06 <vmassol> store.fsattach, store.dbdoc, store.dbattach, etc
17:06 <vmassol> it's a flater namespace
17:06 <vmassol> googling bikeshedding :)
17:07 <cjd> one sec
17:07 <vmassol> ok nice word
17:07 <vmassol> I'll remember it
17:07 <vmassol> :)
17:07 <vmassol> learnt something today!
17:07 <vmassol> yes, 99% of api work is about bikeshedding
17:07 <cjd> http://bikeshed.com/
17:07 <cjd> it's worth a read
17:08 <vmassol> will do but I get the concept
17:08 <cjd> because these kinds of api discussions did a horrific job on the freebsd community
17:08 <vmassol> the problem is when you don't do anything instead of acting
17:08 <cjd> IMO pick something, stick with it enough that a casual user can't spot inconsistancy and ship ship ship :)
17:08 <vmassol> but thinking a bit is not counterproductive IMO
17:09 <vmassol> it must not last too long
17:09 <cjd> in 10 minutes it will have lasted as long as it took to write the patch
17:10 <vmassol> that's not much compared to the cost we will hav eto pay to change the name
17:10 <cjd> a config variable == you don't change it
17:10 <cjd> but if all fsattach is fsattach, store.rdbms is not *obviously* inconsistant
17:12 <vmassol> it wouldn' tbe rdbms, it would be store.rdbmsattach :)
17:12 <cjd> not if we don't do it that way
17:12 <cjd> my point is the users will not notice if we have store.rdbms.someValue
17:12 <cjd> and then on the other side we have store.fsattach.someConfig
17:13 <cjd> nobody is going to notice a thing
17:13 <vmassol> especially since the store module will probably have to go away or be heavily refactored
17:13 <vmassol> since it wasn't coded with the goal of being a replacement to the existing store
17:14 <vmassol> so when we rewrite the existing store, the api will probably be different to take into account all store options
17:14 <vmassol> ok so
17:15 <vmassol> if nobody disagrees with fsattach, we'll keep it and I'll go with the flow, hoping that you'll still be around if we need to change it ;)
17:15 <vmassol> btw this reminds me of a comment from ludovic
17:16 <vmassol> that he would like us to join xwiki.properties and xwiki.cfg
17:16 <cjd> I'd be favorable to that
17:16 <vmassol> because it's too complex for users to have to look at 2 config files
17:16 <cjd> +1
17:16 <vmassol> and now the store config is split in 2 places
17:17 <cjd> Something I've noticed about windows kernel is it's incredibly stupendously well engineered
17:17 <vmassol> so far we tried to have domains defined in either of the 2 files but not in both
17:17 <cjd> designed by people smarter than me, the entire kernel is asynchronous which makes it like the only kernel in the world like that
17:17 <cjd> but writing code to interact with it is impossible
17:18 <cjd> whereas linux is basically a mountain of hacks but they're very fast hacks and writing code for it is really easy because the things you're most likely to do are streamlined
17:18 <cjd> same story with solaris, brilliant beautiful design
17:18 <cjd> takes 200 LoC to open a tun device which can be done in linux with 30
17:19 <cjd> anyway I guess my point is embrase the ugly and make stuff which is really easy to use
17:19 <cjd> :)
17:21 <vmassol> yes sure it really boils down to why you code
17:22 <vmassol> personally I consider it an art and I'm trying to achieve perfection as much as possible
17:22 <cjd> I recognize your position
17:23 <vmassol> of course it's not possible in a not perfect world...
17:23 <vmassol> :)
17:23 <cjd> Do you think I can convince you to read another piece of text when you get a chance?
17:23 <vmassol> hehe
17:24 <cjd> http://zedshaw.com/essays/master_and_expert.html <-- This had a bit of an impact on me as a programmer
17:24 <cjd> that and a lot of pressure to ship ship ship and kill the bugs (in my project)
17:25 <cjd> I guess the difference for me is now I don't really see anything as "complete" anymore.
17:25 <cjd> It's beautiful, it's a beautiful construction site
17:26 <vmassol> oh yes it's never finished I agree about that
17:51 <ClemensR> has left #xwiki
18:00 <kaisen> bye
18:01 <kaisen> has quit
18:05 <vmassol> bye
18:06 <gdelhumeau> has quit
18:06 <lucaa> has quit
18:06 <lucaa> has joined #xwiki
18:08 <vmassol> hey guyes
18:08 <vmassol> just noticed that yesterday was supposed to be the 6.1M2 release :)
18:08 <vmassol> who's the RM already?
18:09 <vmassol> s/guyes/guys
18:13 <vmassol> tmortagne, mflorea: do you remember?
18:15 <woshilapin> has quit
18:16 <mflorea> vmassol: remember what?
18:16 <vmassol> who's the RM for 6.1M2
18:16 <vmassol> (see above)
18:16 <mflorea> see above, (18:08:54) xwikibot: dev:ReleasePlans.ReleasePlan61M2 was created by xwiki:XWiki.mflorea - http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan61M2
18:17 <mflorea> I'll try to release tomorrow
18:17 <vmassol> hmm I dont have this message, strange
18:17 <mflorea> I have to go now
18:17 <vmassol> mflorea: all committers are good?
18:17 <vmassol> ok
18:18 <mflorea> on my side, I have a few small issues that I didn't had time to commit because I worked on File Manager, but nothing critical for 6.1M2
18:19 <vmassol> ok
18:19 <mflorea> has quit
18:19 <vmassol> on my side it should be ok too, I have lots of stuff with @since 6.1M2 but I can change them for RC1 I guess
18:23 <cjd> thx for the catch
18:27 <KermitTheFragger> has quit
18:42 <abusenius> has joined #xwiki
19:13 <tmortagne> has quit
19:28 <Slashman> has quit
19:30 <cjd> has quit
19:39 <vmassol> Lyes: I've added a very first version of the script service implementation. I need to figure out what's the best strategy for testing it now. After you commit the default mime body part factory for String we should have all the pieces to start making the integration test pass :)
19:42 <Lyes> cool, I'll see it
20:04 <webczat> has joined #xwiki
20:04 <webczat> Hello, can all users in xwiki default install modify ui pages in the main space or spaces other than XWiki?
20:05 <vmassol> depends on the space
20:05 <vmassol> for the Main space yes, the default permission allows editing those pages
20:05 <vmassol> but you can set the permission you wish
20:06 <webczat> I meant for example space blog, annotation code etc
20:07 <vmassol> depends
20:07 <vmassol> why?
20:07 <webczat> I know that XWiki is not editable
20:07 <vmassol> you can set the permission you wish on a space
20:08 <vmassol> for ex the Scheduler space is only editable by admins
20:08 <webczat> I've removed all right objects from the wiki to start from default permissions, but I know that default is view, edit, comment/etc for XWikiAllGroup so just excluding guests. I tried to edit Blog/Management as a guest after removing perms and it was allowed
20:09 <webczat> I didn't touch the blog space, just global perms
20:09 <vmassol> if you remove the default permissions then there's no more any default :)
20:09 <webczat> And because all users are added to XWikiAllGroup then...
20:10 <vmassol> I still don't understand what's your problem/question :)
20:10 <vmassol> you want to know how to set up permissions?
20:10 <webczat> Withput any permissions, all users can view, edit and comment, I didn't touch specific spaces. but defaults for the wiki when I don't touch them is probably view, edit and comment for the wiki to XWikiAllGroup.
20:10 <vmassol> there's no such thing as "default permission", the permissions are defined by the rights objects
20:11 <vmassol> try starting your wiki with an empty DB for ex
20:12 <webczat> I know that a new wiki does not have any rights set. guests can view, edit and comment there, can't they?
20:12 <vmassol> actually I don't remember, this may have changed now, let me give you the link to the doc on this
20:13 <vmassol> http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module
20:14 <webczat> I've actually read the docs, I should maybe reread this one again. What I'm actually asking about is a different thing: is it normal that any user having global edit can edit pages like Blog/Management? I could do it as a guest when permissions were changed to all none for him, and defaults for XWikiAllGroup after installing the ui is allow edit.
20:14 <vmassol> when no rights are set any user of the wiki (registered or not) used to be able to do anything (view, edit, admin pr, etc
20:15 <vmassol> now Denis has modified the implementation and I don't remember if that's still the case or not
20:16 <vmassol> webczat: Blog.Management checks for admin right
20:16 <vmassol> you can edit it
20:16 <webczat> It is what I'm asking. Can users do such things by default? I am changing my group layout slightly so I cannot currently check unless using a guest user.
20:17 <vmassol> #if($hasAdmin)
20:17 <vmassol> now
20:17 <webczat> Blog/Management checks for admin right when it is used. but not when it is edited I believe
20:17 <vmassol> I do agree that this page is wrong IMO
20:17 <vmassol> it should have a permission set on it
20:18 <vmassol> since the blog space is not protected
20:18 <vmassol> anyone with edit right could change that page and remove the test
20:18 <vmassol> hmm wait
20:18 <webczat> I tried once from guest. I didn't change anything but I was allowed to save.
20:19 <vmassol> it probably does some checks later on
20:19 <vmassol> for admin
20:19 <vmassol> so you're probably safe
20:19 <vmassol> in any case
20:19 <vmassol> if it calls unrpoetcted api any user with edit rights could also call them :)
20:19 <vmassol> so it's ok
20:20 <webczat> But any user with edit could ctrl+a and del the page :D
20:20 <vmassol> sure
20:20 <webczat> I know, I can change permissions
20:20 <vmassol> but thaty's not a security risk
20:20 <vmassol> any user with edit right can do that on any page he can edit
20:20 <webczat> I can even reimport
20:20 <vmassol> import requires admin perm
20:20 <webczat> and this one is not editable by default
20:21 <webczat> but checking other things. No blog/ page is protected in any way
20:21 <webczat> I believe so at least
20:21 <vmassol> sure that's voluntary
20:21 <vmassol> what's the problem?
20:22 <webczat> I'm just not sure what is and is not protected, like annotation code probably isn't although I'm just trying to read xml
20:23 <vmassol> ok said differenty no page needs to be protected
20:23 <vmassol> because all permissions checks are done at the java level
20:23 <vmassol> so users can only do not dangerous things
20:24 <vmassol> sorry I have to go, dinner time here!
20:24 <vmassol> gl
20:25 <webczat> what about protected api and issues?
21:14 <lucaa> has quit
21:26 <Denis> has quit
22:33 <sburjan> has quit
22:33 <sburjan> has joined #xwiki
22:54 <tekzilla> has quit
22:56 <lucaa> has joined #xwiki
23:11 <tekzilla> has joined #xwiki
23:51 <vmassol> has quit
