IRC Archive for channel #xwiki on 26 August 2015

Last modified by Vincent Massol on 2015/08/26 23:30

<OSIMasson> has joined #xwiki
00:22 <martin-h> has quit
00:24 <martin-h> has joined #xwiki
00:53 <martin-h> has quit
01:19 <abusenius_> has quit
01:22 <martin-h> has joined #xwiki
03:19 <martin-h> has quit
03:24 <martin-h> has joined #xwiki
04:34 <cpe> has quit
04:35 <cpe> has joined #xwiki
05:34 <mflorea> has joined #xwiki
07:15 <msmeria> has joined #xwiki
07:42 <vrachieru> has joined #xwiki
08:21 <cjd> has quit
08:28 <Pbas> has quit
08:29 <tmortagne> has joined #xwiki
08:29 <Pbas> has joined #xwiki
08:30 <KermitTheFragger> has joined #xwiki
08:45 <tmortagne> [WARN] Restarting xwiki.org in 10 minutes
08:45 <ClemensR> has joined #xwiki
09:10 <xwikibot> has joined #xwiki
09:11 <vmassol> has joined #xwiki
09:12 <cjd> has joined #xwiki
09:15 <mflorea> has quit
09:16 <abusenius_> has joined #xwiki
09:40 <mflorea> has joined #xwiki
09:56 <Slashman> has joined #xwiki
10:05 <gdelhumeau> has joined #xwiki
10:11 <gsmeria> has joined #xwiki
10:42 <Ramona2> has joined #xwiki
10:43 <Trefex> has joined #xwiki
11:00 <Trefex> has quit
11:12 <Ramona2> has quit
11:12 <Ramona2> has joined #xwiki
11:40 <Enygma`> has joined #xwiki
11:40 <vmassol> cjd: WDYT about my last comment at: http://jira.xwiki.org/browse/XWIKI-12438?focusedCommentId=87507&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87507
11:41 <cjd> not safe :(
11:42 <cjd> I know there's code which relies on crafted links, some of it is mine
11:42 <vmassol> would it work in your use case for example?
11:42 <vmassol> when I look at the examples at http://extensions.xwiki.org/xwiki/bin/view/Extension/ZIP+Explorer+Plugin they would all work
11:43 <cjd> I nice trick is to do   require(["$xwiki.getAttachmentURL('...')/lib/whatever.js"], function (x) { ...
11:43 <vmassol> that's not a nice trice
11:43 <vmassol> trick :)
11:43 <vmassol> that's an ungly hack
11:44 <vmassol> its much better to do $xwiki.zipexplorer.getLink(...)
11:44 <vmassol> *getFileLink()
11:45 <cjd> Well it's easier to remember 1 API function than 2 so I know there's tons of that stuff
11:45 <vmassol> it's exactly the same as for webjars
11:45 <vmassol> you could try to make the URL yourself
11:45 <vmassol> but you're doomed if you do
11:45 <vmassol> that's why we provide $services.webjrs.url(...)
11:46 <vmassol> that allows us to change the impl
11:46 <cjd> but at any rate, after /lib/whatever.js executes, it will probably pull in other things via relative URL because requirejs allows that
11:46 <vmassol> which we did!
11:46 <cjd> if you do, you're going to break prod
11:46 <cjd> :)
11:46 <vmassol> there'sno other way
11:46 <vmassol> to support NS
11:46 <vmassol> so it's either we don't support NS in zipexplorer
11:47 <evalica> has joined #xwiki
11:47 <vmassol> or we do this which I find very acceptable
11:47 <vmassol> I need other people's opinions here
11:47 <cjd> Anca's on the phone but I'll grab her as soon as she's off :D
11:48 <vmassol> ok
11:49 <vmassol> make sure to mention that if it's not that then no NS support
11:49 <cjd> refusing to support zipexplorer for NS would be ok because when people upgrade, it won't explode
11:49 <vmassol> (which is also going to break prod in the future)
11:49 <vmassol> it'll explode
11:49 <cjd> it'll explode when people move things into NS's
11:49 <vmassol> whenever they create a new page and try to use the plugin
11:49 <cjd> which is a bit expected
11:49 <vmassol> they'll move by default
11:49 <vmassol> since creating a new page created a NS
11:49 <vmassol> *creates
11:50 <cjd> hrm
11:50 <vmassol> but yes at least it'll work when they upgrade if they don't touch anything
11:50 <cjd> that's a big deal because people are in a bad mood when they are upgrading and it's never a good idea to give them reason to think about you when they are in that mental state
11:51 <cjd> better they face that issue another day
11:51 <cjd> Is there really no way to hack zipexplorer NS support ?
11:51 <vmassol> I don't see a realistic one
11:51 <vmassol> but really
11:52 <vmassol> if they comptue the url themselves when we provide an api
11:52 <vmassol> it's really themseves they can blame for it
11:52 <cjd> "they" are long gone
11:52 <cjd> the person who will be mad will be the person upgrading
11:52 <vmassol> its like using a bug and then compaining when it's fixed
11:52 <cjd> re Sim City
11:52 <cjd> memory allocator
11:53 <vmassol> the thing is this is an old plugin that is not used that often
11:53 <cjd> it's used enough
11:54 <vmassol> ok then I know what I can do, commenting
11:54 <cjd> Windows 95 team tested each application while upgrading because their logic was that if someone bought Sim City and then a year later they bought Windows 95, upgraded and Sim City stopped working, they would not call Sim City and demand to return it, they would take Windows 95 back to the store
11:55 <cjd> And in the case of Sim City, it was using memory after it was freed, something which happened to work ok with the older memory allocator but with the new (more agressive) one it caused crashes
11:55 <vmassol> new proposal: http://jira.xwiki.org/browse/XWIKI-12438?focusedCommentId=87509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87509
11:55 <cjd> so they wrote a special detection mode which detected Sim City and switched the memory allocator to preserve memory when it was freed so that it would not crash
11:55 <tmortagne> vmassol: the new ?path= parameter you propose would be a new thing ?
11:56 <vmassol> the zipexplorer plugin is not the reason people use xwiki :)
11:56 <vmassol> tmortagne: yes
11:56 <cjd> sort of but zipexplorer is in common use
11:57 <vmassol> anyway look at my last proposal cjd
11:57 <cjd> right, that should work
11:57 <vmassol> which btw I can only do by breaking backward compat slightly
11:57 <tmortagne> vmassol: what "Make it work" means exactly
11:57 <tmortagne> ?
11:57 <vmassol> commenting on that since I didn't mention it
11:58 <cjd> I think it could be a tiny bit more clever but that will at least mean that upgrades do work
11:59 <vmassol> commented
12:00 <cjd> hm
12:01 <vmassol> commented more
12:01 <cjd> should work
12:01 <cjd> I would put some 3vil hax in DownloadAction
12:01 <tmortagne> vmassol: won't URL parameter based path break navigation is a zip like a javadoc package for example ?
12:01 <vmassol> it's not enough
12:02 <cjd> mm actually what you're doing is indeed ok
12:02 <tmortagne> which used to be our main use case for zip plugin
12:02 <cjd> just make sure that any other plugins which implement downloadAttachment() do not explode fantastically if they get a null
12:03 <vmassol> tmortagne: you mean getFileTreeList()?
12:03 <cjd> and then put the 3vil in the plugin
12:03 <tmortagne> vmassol: no idea what getFileTreeList() is, I mean you access the root index.html in a javadoc package and then click a link -> you end up nowhere
12:04 <vmassol> ah I see what you mean
12:04 <vmassol> indeed that will break it I think
12:05 <cjd> so we are forced to use /zipexplorer/space/space/document/attachment/path/to/whatever.html
12:05 <vmassol> no
12:05 <vmassol> we can introduce a marker in the URL in the new format
12:05 <tmortagne> since that's the way we used to document API in http://platform.xwiki.org/xwiki/bin/view/DevGuide/API it does not sounds very acceptable to break it
12:05 <vmassol> to separate the attachment part from the zip path part
12:05 <vmassol> (as a rest api would do)
12:06 <vmassol> for example:
12:06 <cjd>  /download/space/space/document/attachment//path/to/whatever.html ?
12:06 <tmortagne> if zipexplorer has its own URL an easy one is /zipexplorer/space.space.document@attachment/path/to/whatever.html but it's not very consistent with other URLs
12:07 <vmassol> for ex: /download/space1/space2/page/attachment/zippath/path/inside/zip yes
12:07 <cjd> remember I said that we should not allow a nested space with the same name as an attachment? :)
12:07 <vmassol> I don't really want to change too many things at this stage
12:07 <vmassol> since we need to rewrite the plugin into components
12:08 <vmassol> but indeed we could think about what url we would want when we rewrite it
12:08 <vmassol> so save one step
12:08 <vmassol> *to
12:08 <vmassol> but it means adding a new mapping
12:08 <vmassol> and new Action
12:08 <martin-h> has quit
12:09 <vmassol> I wasn't prepared to go that far right now… :)
12:09 <vmassol> (with the little time we have)
12:10 <vmassol> cjd: that doesn't make any sense since attachment can have all the possible names
12:10 <martin-h> has joined #xwiki
12:10 <cjd> block upload of an attachment w/ same name as NS or creation of NS w/ same name as attachment
12:10 <vmassol> yuck
12:11 <tmortagne> cjd: that does not really work, it makes import a nightmare
12:11 <cjd> indeed import becomes a mess
12:11 <tmortagne> plus it's really hard to understand that you can't attach some file because a space somewhere not related at all has the same name
12:11 <vmassol> and it won't help anyway with the problem we have
12:12 <cjd> that's all in how you show it
12:12 <cjd> POSIX prevents a file and a folder w/ same name
12:12 <tmortagne> and anyway yes it's does not help sinc ethe issue is not name collision but where does reference stops and where path starts
12:12 <vmassol> you still don't know where the zip path starts
12:13 <cjd> mmm
12:13 <tmortagne> cjd: it prevent it in the exact same folder, I don't see the relationship
12:13 <tmortagne> you won't have an attachment in the same place than a space since an attachment is in a page by definition
12:13 <cjd> nested space is like a sub-folder to me
12:13 <vmassol> tmortagne: I already mentioned this to cjd when he mentioend this idea :)
12:13 <tmortagne> but anyway again it's not the issue
12:14 <vmassol> yup
12:14 <cjd> so download/A/B/C/D/E/F
12:14 <cjd> is A a space ?
12:14 <cjd> if so, is B a space
12:15 <cjd> etc until one is not a space
12:15 <cjd> assuming A and B are spaces, is C a page ?
12:15 <cjd> argh, page and space are the same
12:15 <cjd> s/page/space/ :)
12:15 <cjd> still works
12:15 <vmassol> AB.C.D are spaces, E is a page, F is an attachment name
12:16 <vmassol> that's the current format for the "standard" url scheme
12:16 <cjd> ok E is a page, we can determine that by walking the list
12:16 <cjd> so we check for attachments called F
12:16 <cjd> if there is an attachment called F, we decend into it
12:16 <cjd> but since A and B are also space/pages we need to check for attachment B in space/page A
12:17 <cjd> and attachment C in page B.WebHome
12:17 <cjd> as soon as we hit a matching attachment, we decent into it
12:17 <tmortagne> you can't know what /A/B/C/D/E/F is the context of zip plugin
12:17 <cjd> You can but you have to search
12:17 <vmassol> and trying all combinations is not good for perf POV
12:17 <tmortagne> not even
12:18 <cjd> well it's how a filesystem finds a file
12:18 <tmortagne> it's not a filesystem
12:18 <vmassol> I already commented why cjd
12:18 <cjd> getDocument(A.WebHome).getAttachment(B)
12:18 <cjd> getDocument(A.B.WebHome).getAttachment(C)
12:18 <cjd> etc
12:18 <cjd> that *will* work and not destroy anything existing
12:19 <vmassol> perf perf perf
12:19 <tmortagne> that does not work either because you have no idea we search for a Webhome first
12:19 <tmortagne> and it's not because some level exist that it's the one you wanted
12:19 <vmassol> (that too)
12:19 <cjd> the namespace collision problem is going to exist
12:20 <vmassol> the complexity shows it's not the right solution
12:20 <tmortagne> without something in the URL it's simply impossible to properly support NS in the zip plugon
12:20 <tmortagne> nothing to do with performances
12:20 <vmassol> you could accept some colliison thomas
12:20 <vmassol> but perf degradation is not acceptable
12:20 <cjd> Well.. we're not sure what the perf degradation actually is
12:21 <tmortagne> a "solution" that has collision is not a solution IMO
12:21 <cjd> if any solution w/ a collision is not acceptable then you have sunk yourselves because you allowed subspaces and attachments to have the same name
12:22 <tmortagne> IMO the only solution is a new URL scheme for the zip plugin and a retro compatibility support of old single space URLs
12:22 <cjd> but actually if you go from the end backward, it's mostly hits to exists()
12:22 <tmortagne> cjd: you can access the space or the page whenever you want
12:22 <cjd> if (exists(A.B.C.E.F)) {
12:23 <cjd> if (exists(A.B.C.E)) {
12:23 <cjd> etc
12:23 <cjd> err
12:23 <tmortagne> we are talking about a blocking collision here for zip explorer which is not acceptable IMO
12:24 <tmortagne> i.e. no way at all to access some attachment files
12:24 <cjd> yeah.... allowing the same name for subspaces and attachments :)
12:25 <evalica> has quit
12:27 <vmassol> commented on the 2 formats that would work
12:29 <cjd> Implementing both would provide maximum safety, there is a collision in there but it's in the "legacy" format which people should not use
12:33 <cjd> commented
13:25 <vrachier1> has joined #xwiki
13:27 <vrachieru> has quit
13:27 <evalica> has joined #xwiki
13:43 <Enygma`> has quit
13:44 <Enygma`> has joined #xwiki
14:31 <cjd> has quit
14:40 <cjd> has joined #xwiki
14:41 <vmassol> has quit
14:42 <vmassol> has joined #xwiki
14:43 <vmassol> another mac crash… grrrr
14:43 <vmassol> 2 in 2 days
15:02 <msmeria> has quit
15:19 <Trefex> has joined #xwiki
15:20 <gdelhumeau> vmassol: funny. I'm thinking about switching to mac since I have some crashes with linux
15:20 <vmassol> :)
15:23 <tmortagne> no crashes on my side :)
15:25 <gdelhumeau> my next computer will probably be a mac anyway
15:26 <gdelhumeau> want to try it
15:26 <gdelhumeau> and don't want to waste time configuring my linux
15:29 <tmortagne> I usually don't need to configure much with Ubuntu, last time I installed it I got all drivers working and just needed to deal with my own stuff like Eclipse etc
15:29 <tmortagne> (even with optimus now)
15:32 <gdelhumeau> because your laptop is not new
15:33 <gdelhumeau> when I had my own, there were no drivers for the wifi card
15:33 <gdelhumeau> and I was no aware about optimus
15:33 <gdelhumeau> so it was a pain at the time
15:33 <gdelhumeau> now it's ok
15:33 <gdelhumeau> but still have some special conf to make intellij work correctly
15:35 <gdelhumeau> and I have to debug to understand why my external hard drive is not recognized anymore
15:35 <gdelhumeau> I am a bit tired of that
15:44 <tmortagne> Eclipse works well :)
15:46 <helge_> has joined #xwiki
15:49 <helge_> Hi, I find page edit does not work in 7.1.2 with Firefox 40.0. The editor does not appear. Works with chromium and other browsers, though.
15:49 <fcharton> has joined #xwiki
15:49 <tmortagne> helge_: works well for me, you should maybe try to clean your browser cache
15:54 <helge_> still not working - I try to find out more...
15:58 <helge_> very strange - I test different screen sizes in firefox. Edit mode works for screens up to 991px wide but fails for larger screens.
15:59 <helge_> I have text editor set as default for my user
16:04 <tmortagne> I'm on a 1080p
16:04 <helge_> Same error in Chromium - had a smaller window before.
16:12 <helge_> occurred after upgrade from 7.1.1.
16:46 <tbb_> has joined #xwiki
16:46 <gsmeria> has left #xwiki
17:00 <tmortagne> has quit
17:06 <sorinello> has quit
17:12 <cjd> has quit
17:20 <KermitTheFragger> has quit
17:27 <cjd> has joined #xwiki
17:37 <evalica> has quit
17:44 <helge_> has quit
17:55 <gdelhumeau> has quit
18:03 <Trefex> has quit
18:09 <tbb_> has quit
18:26 <mflorea> has quit
18:33 <cjd> has quit
19:08 <Enygma`> has quit
19:15 <vrachier1> is now known as <vrachieru>
19:24 <cjd> has joined #xwiki
19:30 <Ramona2> has quit
19:58 <ClemensR> has quit
20:22 <mflorea> has joined #xwiki
20:50 <gsmeria> has joined #xwiki
20:50 <Ramona1> has joined #xwiki
20:50 <gsmeria> has left #xwiki
20:54 <Chuguniy> has joined #xwiki
20:58 <mflorea> has quit
21:09 <Ramona1> has quit
21:14 <Slashman> has quit
22:18 <Chuguniy> has quit
22:50 <benoitc> has quit
22:52 <benoitc> has joined #xwiki
22:52 <Trefex> has joined #xwiki
23:08 <vrachieru> has quit
23:14 <vrachieru> has joined #xwiki
23:14 <Chuguniy> has joined #xwiki
23:15 <MasterPiece> has joined #xwiki
23:30 <MasterPiece> has quit
Tags:
   

Get Connected