IRC Archive for channel #xwiki

CalebJamesDeLisl - (00:00): It seems that if one has the choice of making a proposal or a vote, the proposal is a better idea since they don't block themselves if nobody takes an interest.
vmassol left at 00:01 (Quit: Leaving.
lucaa - (00:01): yes, but it's about the importance of the changes and how confident you feel about them. I'm not very much pro voting all kind of things, because we endup having a lot of votes that we don't have time to answer
CalebJamesDeLisl - (00:03): I think API is the most important thing there is and that's why I kept proposing this since the 15th hoping to get some response.
vmassol joined #xwiki at 00:04
vmassol - (00:05): CalebJamesDeLisl: back, couldn't resist answering that last comment
vmassol - (00:05): :)
CalebJamesDeLisl - (00:05): :)
CalebJamesDeLisl - (00:05): I know the feeling.
vmassol - (00:05): a vote shouldn't be considered as something blocking you
vmassol - (00:05): it's quite the opposite
lucaa - (00:05): "somebody's wrong on the internet"
vmassol - (00:05): when you do a vote it's because you're asking for advice from people
vmassol - (00:06): you want to be sure you're doing it right
vmassol - (00:06): since if you don't you'll have to suffer the consequences (and the others too)
CalebJamesDeLisl - (00:07): That makes sense, perhaps this should be codified in the committership page. You can send the vote for that one ;)
vmassol - (00:07): ;)
CalebJamesDeLisl - (00:07): You have my +1
CalebJamesDeLisl - (00:07): So (in my understanding) it's committed as a proposal if the vote is ignored.
vmassol - (00:07): ok really going to be now
vmassol - (00:08): I'll let you guys figure out the solution to all this!
CalebJamesDeLisl - (00:08): Good night.
vmassol left at 00:08 (Client Quit
CalebJamesDeLisl - (00:16): going to make pizza...
lucaa - (00:16): have fun Caleb
DV left at 00:17 (Ping timeout: 276 seconds
CalebJamesDeLisl - (00:34): Back. In the common law there is a term called acquiescence. When one notices a potential infringement of their rights and remains silent for a given amount of time, they lose their right to challenge it. ( http://en.wikipedia.org/wiki/Acquiescence )
CalebJamesDeLisl - (00:36): An analogy to this would be to say if one does not reply to a vote in a reasonable amount of time (does not even ask for more information), then they cannot ask for the change to be removed later on.
CalebJamesDeLisl - (00:38): Where lazy consensus does not specify that the lazy consentors must have notice of the pending change and they retain the right to demand that the change is removed.
CalebJamesDeLisl - (00:41): In the doctrine of acquiescence, it is central that the "lazy consentors" must have notice of the pending change and be given reasonable time to request further information or give their -1. But once the change is made, they give up their right to demand it's removal.
CalebJamesDeLisl - (00:43): I don't see other committors having trouble getting things passed so this is probably not useful in our case, but it's something to consider.
sdumitriu - (00:50): Caleb, but another committer can raise a problem that convinces you to revert
sdumitriu - (00:51): Like, if somebody were to come in two weeks and say Stop, this change is a major security hole, you would revert it, right?
CalebJamesDeLisl - (00:51): Of course, but the implied right which comes with lazy consensus would not be there.
CalebJamesDeLisl - (00:53): And nothing is ever above another vote, so even if our rogue committor felt attached to his security hole, he could be overridden by a vote :)
CalebJamesDeLisl - (00:56): Pizza's ready.
sdumitriu - (00:56): Share?
jvelociter joined #xwiki at 01:18
anamarias left at 02:08 (Quit: anamarias
nickless joined #xwiki at 02:14
nickless left at 02:42 (Ping timeout: 264 seconds
bbc581 left #xwiki at 03:03
cypromis left at 03:56 (Remote host closed the connection
cypromis joined #xwiki at 03:56
DV joined #xwiki at 04:23
DV left at 04:24 (Read error: Connection reset by peer
sdumitriu left at 04:39 (Ping timeout: 246 seconds
Denis left at 07:01 (Read error: Connection reset by peer
mflorea joined #xwiki at 07:01
Denis joined #xwiki at 07:08
plunden left at 07:38 (Ping timeout: 276 seconds
plunden joined #xwiki at 07:46
vmassol joined #xwiki at 07:58
DV joined #xwiki at 07:59
DV_ joined #xwiki at 08:04
CalebJamesDeLisl - (08:05): Good morning, I found I can add some protection to the mail server by storing the smtp username and password in FriendInviterConfig which can be set only viewable by admins but it will duplicate the smtp username and password fields in XWikiPreferences.
DV left at 08:05 (Ping timeout: 260 seconds
Denis - (08:15): Hi Caleb, ?1, this have to a done in a global way, I see no point to have separate settings. The global settings should be improved however.
Denis - (08:15): s/to a done/to be done/
CalebJamesDeLisl - (08:16): The pb is that XWikiPreferences has to be visible to everyone, so that username and password is public.
CalebJamesDeLisl - (08:17): I do see a use case for having a different from address for the inviter even if it is required to use the same relay.
Denis - (08:18): for the from adresse I agree, this has nothing to do with the username/password securing the server
CalebJamesDeLisl - (08:18): How about if the fields are there but if not filled they default to the global values?
Denis - (08:19): to stay secure, the best is to not have to use one, and to secure the access to the smtp server using other methods
Denis - (08:20): IMHO, I see no point to have more than one
Denis - (08:20): if you want, these could be also in xwiki.cfg AFAIK
CalebJamesDeLisl - (08:21): see: http://jira.xwiki.org/jira/browse/XPMAIL-7
Denis - (08:22): currently, I cannot get at it, sorry, thomas has not finish the work on JIRA for my access I think
CalebJamesDeLisl - (08:27): Suppose the admins are using an external mail service and want to send from different addresses depending on the type of mail, in that case the username and password would have to be different.
plunden1 joined #xwiki at 08:56
Denis - (08:57): that makes sense, but then it should be an override of the default global settings
CalebJamesDeLisl - (09:02): That's what I was thinking, maybe I can hide the fields in the configuration page then scroll them into view when an "advanced" tab is clicked.
CalebJamesDeLisl - (09:04): Something else I thought of re configuration, There are things other than configuration which we want to save on upgrade eg: the document containing all of the stored email objects.
Denis - (09:05): but is that one installed ?
CalebJamesDeLisl - (09:06): I suppose ot could be created on the fly, it's rights would have to be set so only admins could view.
CalebJamesDeLisl - (09:06): s/ot/it
CalebJamesDeLisl - (09:07): I think it would be nice to be able to tag different documents with group names then export all document in a given group to xar.
Denis - (09:11): grouping documents for export is currently a function of the appmanager, but it could be improved, I feel this is something that should be in the new one
CalebJamesDeLisl - (09:11): The new one?
Denis - (09:12): http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager
CalebJamesDeLisl - (09:14): Ahh yes, RedHat package manager for XWiki.
CalebJamesDeLisl - (09:16): RPM supports the idea that a package can list itself as an upgrade for another package and if it isn't an upgrade but they have files by the same name, it won't let you install both at once.
silviar joined #xwiki at 09:23
anamarias joined #xwiki at 09:31
vmassol left at 09:39 (Quit: Leaving.
vmassol joined #xwiki at 09:42
DV_ left at 09:46 (Quit: Leaving
DV joined #xwiki at 09:47
arkub joined #xwiki at 10:02
Denis left at 10:05 (Quit: Leaving.
lucaa left at 10:10 (Quit: Leaving.
florinciu joined #xwiki at 10:15
jvdrean joined #xwiki at 10:16
kibahop left #xwiki at 10:18
gvallarelli joined #xwiki at 10:27
gvallarelli - (10:27): hello and good morning
glerouge joined #xwiki at 10:28
glerouge left at 10:34 (Quit: Leaving.
jvelociter - (10:37): good morning
Denis joined #xwiki at 10:37
lucaa joined #xwiki at 10:45
plunden left at 10:47 (Ping timeout: 258 seconds
mflorea left at 10:48 (Quit: Leaving.
anamarias - (10:54): hi
anamarias - (10:54): I have a question concerning user rights
anamarias - (10:54): so, I have:
anamarias - (10:54): - a livetable with pages in space X
anamarias - (10:54): - user U which belongs to XWikiAllGroup
anamarias - (10:54): Question:
anamarias - (10:54): - what rights should user U have to see the actions column for each of the pages in the livetable?
vmassol - (10:56): anamarias: hi, no idea but have you checked the code ?
vmassol - (10:57): should be either in Livetable*Result or in macros.vm
anamarias - (10:57): code where?
anamarias - (10:57): ah
anamarias - (10:57): I know it should be admin, but I can't remember on what exactly
vmassol - (10:59): http://localhost:8080/xwiki/bin/edit/XWiki/LiveTableResultsMacros?&editor=wiki
tmortagne joined #xwiki at 11:00
vmassol - (11:01): anamarias: actualy I think the checks are in macros.vm
vmassol - (11:01): search for livetable in macros.vm
anamarias - (11:03): thanks, anyways, I'm sure it's not a problem from our side
lucaa - (11:03): anamarias: you can only be admin on a wiki
lucaa - (11:03): not on space or doc
vmassol - (11:04): tmortagne: I'm not super happy with my code for LinkReferenceSerializer but I don't see a solution apart from a big refactoring to make renderers components
vmassol - (11:04): actually I could pass a component manager instance around too
tmortagne - (11:04): vmassol: well renderer are components :) i mean sub renderer ?
vmassol - (11:04): a bit heavy but offers CI
vmassol - (11:05): tmortagne: for ex XWikiSyntaxChainingRenderer is not a component
anamarias - (11:06): lucaa: can't you administer just a particular space or page :( ?
anamarias - (11:06): I need to give users ability to delete or rename just some of the pages in particular spaces
anamarias - (11:06): isn't this possbile?
vmassol - (11:06): tmortagne: passing a CM is probably the best solution unless we make them components
lucaa - (11:07): anamarias: you can give the delete right to the users on that space
lucaa - (11:07): and edit I think, to rename (i'm not sure)
lucaa - (11:07): admin is to be interpreted as administration in general, not only the sum of delete & edit & all
anamarias - (11:08): ah :(
lucaa - (11:08): that's why it's a global right, not a space or page one
lucaa - (11:08): what would administer page mean?
tmortagne - (11:08): vmassol: passing CM seems ok
vmassol - (11:08): tmortagne: ok doing it
nickless joined #xwiki at 11:09
lucaa - (11:10): CalebJamesDeLisl: this should have a fix version set  XWIKI-5041
CalebJamesDeLisl - (11:11): Thanks, I forgot.
vmassol - (11:11): tmortagne: only issue is handling exceptions when doing a lookup from CM… hmmm…. I'll pass the looked up instance instead of the CM I think
tmortagne - (11:13): if you want to fail lookup the renderer when one of its requirement s not found indeed
nickless left at 11:15 (Read error: Operation timed out
florinciu left at 11:19 (Read error: Connection reset by peer
Enygma` joined #xwiki at 11:31
anamarias - (11:34): can special characters be used in document names? like *garçon or étalage* ?
lucaa - (11:36): anamarias: yes, they should. However the number of bugs could depend on the version you are
jvelociter - (11:36): tmortagne: the hot database re-connect is very pleasant, kudos !
tmortagne - (11:36): jvelociter: you mean vmassol
jvelociter - (11:37): ah right, vmassol, sorry
anamarias - (11:37): lucaa: it's 2.0.2. how many :P ?
jvelociter - (11:37): kudos vmassol :)
vmassol - (11:37): jvelociter: hehe cool, glad you like it ;)
lucaa - (11:38): anamarias: :) I couldn't tell you an exact number but probably more than in the recent versions
lucaa - (11:38): however a lot better than older version iirc. Now, are you having problems with that or you just asked to make sure?
anamarias - (11:38): how can I identify those bugs on jira? (what filters)
lucaa - (11:39): you can do a search
anamarias - (11:39): there are problems, but not sure exactly which yet, as they're not completely specified :p
lucaa - (11:39): right
lucaa - (11:40): well, rule is it should work, unless you hit a bug
florinciu joined #xwiki at 11:40
lucaa - (11:41): I'd say the right approach is to identify bugs you have and then try to see if they're reported and fixed in recent versions rather than the other way around
anamarias - (11:43): yup, you're right, better this way
anamarias left at 11:48 (Quit: anamarias
CalebJamesDeLisl - (11:52): Nap time, need rest before trying to install qmail.
mflorea joined #xwiki at 11:54
evalica joined #xwiki at 11:54
anamarias joined #xwiki at 12:02
sdumitriu joined #xwiki at 12:10
tmortagne - (12:11): I'm starting to prepare the release plan and will start the 2.2.4 release soon
vmassol - (12:12): tmortagne: fyi what I committed doesn't fix the wysiwyg issue re special chars
vmassol - (12:12): mflorea or lucaa still need to call it
tmortagne - (12:12): hmm
vmassol - (12:12): it's not much, probably a 2 lines change
tmortagne - (12:12): we could loose things if the WYSIWYG does not use it
vmassol - (12:13): it's generating invalid links
vmassol - (12:13): for example for a page named "page." it will generate
vmassol - (12:13): [[label>>space.page.]]
vmassol - (12:13): instead of [[label>>space.page\.]]
vmassol - (12:14): actually I think the pb is that anca isn't calling the server
tmortagne - (12:14): WYSIWYG does no already suport the document reference escaping ?
tmortagne - (12:14): you just added escaping support for link reference chars like @/?/&
vmassol - (12:14): she's recoded reference handlung
vmassol - (12:14): so this would need to be removed and the real code called
vmassol - (12:14): lucaa: can you confirm?
vmassol - (12:14): (I talked to mflorea yesterday; he was supposed to talk to you)
vmassol - (12:15): tmortagne: yes there were 2 problems
lucaa - (12:15): vmassol: yes I did recode it, client side
lucaa - (12:15): and so yes, it need to be updated to handle these cases
vmassol - (12:15): (actually 4 in total but the other 2 are minor compared to this)
mflorea - (12:15): vmassol, tmortagne: yes, it's not that easy to fix this (not two lines anyway)
vmassol - (12:15): lucaa: I'd rather we don't recode stuff
vmassol - (12:15): since it causes these kinds of issues
vmassol - (12:16): (the wysiwyg editor is now broken because of duplicate code)
lucaa - (12:16): vmassol: if it was only a matter of preference I wouldn't have done it either
tmortagne - (12:16): so we already have escaping issue compared to rendering in 2.2.3 ?
vmassol - (12:16): yes
tmortagne - (12:16): ok so less critical to suport what you just added then
tmortagne - (12:17): but still not very nice, i did not know we had this issue
vmassol - (12:17): sure, there are now 2 bugs instead of one ;)
vmassol - (12:17): I didn't either know either
vmassol - (12:17): I was suprised to discover it
lucaa - (12:17): mflorea: you want to talk about it?
jvdrean left at 12:18 (Quit: Leaving.
mflorea - (12:19): vmassol: it can't be fix for 2.2.4.
mflorea - (12:19): lucaa: wdym?
lucaa - (12:19): if you want to talk about how to go to fix this thing, with client side references for the wysiwyg
vmassol - (12:19): tmortagne: should I still merged my code? hmmm
vmassol - (12:20): I guess we might still have a 2.2.5
tmortagne - (12:20): vmassol: i already committed the escaping handling so better merge the rest of the code
mflorea - (12:20): lucaa: not now. I'd have to look over the code first
vmassol - (12:21): I'll merge against the issue but it won't be closed since marius won't have the time to fix it
vmassol - (12:21): I think it's ok since it doesn't add anything user-related
lucaa - (12:21): mflorea: ok, how you want. I could tell you some stuff about it
tmortagne - (12:21): vmassol: and yes the WYSIWYG part should be fixed in 2.2.5 if possible
vmassol - (12:21): (otherwise we need a new issue but it's probably overkill)
tmortagne - (12:22): it change the way the source is parsed, it's pretty user related to me
tmortagne - (12:22): IMO there should be another issue for the WYSIWYG
vmassol - (12:22): I'm talking about the new internal link reference serialize
vmassol - (12:22): this is not user related
vmassol - (12:22): it's an internal refactoring
tmortagne - (12:22): sure this one is part of the existing issue
vmassol - (12:22): (except for the little detail that since it's a component the interface is exposed)
tmortagne - (12:22): but the issue should then be closed
vmassol - (12:23): err?
mflorea - (12:23): tmortagne: sure, we need a new issue for handling the escape on the wysiwyg side
mflorea - (12:23): I'll handle that
vmassol - (12:23): mflorea, tmortagne: the issue is ther already
vmassol - (12:23): marius I4v epinged you on skype this morning
mflorea - (12:23): where?
tmortagne - (12:23): vmassol: you commmitted stuff for 2.2.4 et 2.3M2 i don't see why it should not be closed
vmassol - (12:23): because we don't need issues for internal refactorings
mflorea - (12:23): vmassol: right, sorry
vmassol - (12:24): now ther's the exception of the new interface
vmassol - (12:24): but it's technical
vmassol - (12:24): so we can choose not to create a new issue or we can create one
tmortagne - (12:24): vmassol: your issue is not only about link reference serialize
vmassol - (12:24): (I can do it although it's a bit overkill)
tmortagne - (12:24): you change the way syntaxe is parsede
tmortagne - (12:24): again
vmassol - (12:24): errr?
vmassol - (12:24): I didn't
vmassol - (12:24): you're mixing issues
tmortagne - (12:24): you added escaping support
vmassol - (12:24): nope
vmassol - (12:24): I only introduced a serialize
vmassol - (12:24): serializer
tmortagne - (12:25): XWIKI-4957: Allow entering @, ? and # characters in link references
tmortagne - (12:25): this is committed in 2.2.4
vmassol - (12:25): this one is old
vmassol - (12:25): and closed
tmortagne - (12:25): that's the one i'm talking about
vmassol - (12:25): why would you want to reopne it?
tmortagne - (12:25): it's you that dont want to close it...
vmassol - (12:25): it's ALREADY  closed
vmassol - (12:25): wy would I want to reopne it?
vmassol - (12:26): mix up
vmassol - (12:26): apparently
vmassol - (12:26): I'm talking about the wysiwyg issue
vmassol - (12:26): from the beginning
vmassol - (12:26): the one I created this morning
vmassol - (12:26): against which I committed my code this morning
tmortagne - (12:26): vmassol: for me the link refactoring was part of the same issue
vmassol - (12:26): and against which I'll commit in a few seconds in the 2.2. branch
mflorea - (12:26): http://jira.xwiki.org/jira/browse/XWIKI-5066
tmortagne - (12:26): you created an new issue whcih is useless
tmortagne - (12:26): i did not seen that
vmassol - (12:27): ok
vmassol - (12:27): it's good I did that
vmassol - (12:27): since we cannot close that new issue
tmortagne - (12:27): you committed stuff for it so we ill have to close it...
vmassol - (12:27): (which is for wysiwyg btw)
vmassol - (12:27): nope
vmassol - (12:27): this is what I explained above
vmassol - (12:28): it's a choice
vmassol - (12:28): I could have put no issues at all
vmassol - (12:28): (in other words)
vmassol - (12:28): depedns if we want to be 100% strict or not
vmassol - (12:29): I could svn edit the commit message
vmassol - (12:30): and put it against 4957
vmassol - (12:30): ok I'll do that
vmassol - (12:33): tmortagne: done
tmortagne - (12:38): ok
bbc581 joined #xwiki at 12:43
tmortagne - (12:43): is anyone has something to commit before 2.2.4 ? If not i'm starting
vmassol - (12:44): npm: were you able to test 2.2.4 in the end?
vmassol - (12:44): tmortagne: nothing from me
vmassol - (12:44): tmortagne: there are pb with renames and special chars but that'll be in 2.2.5
tmortagne - (12:44): all: don't forget to close issues you already commmitted
sdumitriu - (12:48): tmortagne: I would like to commit something, but I won't have time until tonight
sdumitriu - (12:48): So, if you're in a hurry, go ahead with the release
tmortagne - (12:48): sdumitriu: is it critical ? Otherwise we already know we will release a 2.0.5
tmortagne - (12:48): 2.2.5
vmassol - (12:48): 2.2.5
sdumitriu - (12:48): Well, Ludo needs it before the end of the month
sdumitriu - (12:49): (The upgrade for css4j)
vmassol - (12:49): nope
vmassol - (12:49): well
vmassol - (12:49): he also needs 2.2.4 before tomorrow
vmassol - (12:49): so indeed that could go in a 2.2.5
vmassol - (12:50): err
vmassol - (12:50): you mean end of march or april?
vmassol - (12:50): because we're already at end of march :)
vmassol - (12:50): so we need to talk to him then
jvdrean joined #xwiki at 12:54
bbc581 left at 12:58 (Ping timeout: 264 seconds
sdumitriu - (12:59): Actually I don't remember which month
tmortagne - (13:07): sdumitriu, vmassol: ludo said it was just a nice to have
tmortagne - (13:08): (he patched for his needs)
tmortagne - (13:08): so i'm starting the release
vmassol - (13:15): ok
florinciu left at 13:21 (Read error: Connection reset by peer
florinciu joined #xwiki at 13:29
vmassol left at 13:31 (Quit: Leaving.
vmassol joined #xwiki at 13:31
vmassol - (14:04): sdumitriu: shouldn't proposal 12A for the logo be discarded since it's very close to the xwiki.com logo?
sdumitriu - (14:05): Maybe
vmassol - (14:05): re proposal Y I'm not sure we should discard it
vmassol - (14:06): (we have an X in our name which justifies it)
shelan_ joined #xwiki at 14:19
DV left at 14:31 (Read error: Connection reset by peer
jvdrean left at 14:37 (Ping timeout: 268 seconds
arkub left at 14:37 (Ping timeout: 268 seconds
anamarias - (14:40): is there a way to handle exceptions thrown from components and scripts, like for example: by configuration a global exception handler in struts or so to send email when exceptions are thrown?
jvdrean joined #xwiki at 14:43
KermitTheFragger joined #xwiki at 14:57
Enygma` left at 14:59 (Quit: Leaving.
sdumitriu - (15:02): "description" : "", "description_value" : "${fieldvalue}",
sdumitriu - (15:02): Sorry, wrong window
arkub joined #xwiki at 15:03
shelan_ left at 15:08 (Quit: Leaving
KermitTheFragger left at 15:16 (Quit: Leaving
florinciu left at 15:21 (Read error: Connection reset by peer
xwikibot joined #xwiki at 18:07
vmassol - (18:07): we just fixed a bug
lucaa - (18:07): http://jira.xwiki.org/jira/browse/XE-632
vmassol - (18:07): standalone/inline macros
jvelociter - (18:07): ok, it's a bug
DV left at 18:09 (Ping timeout: 260 seconds
gvallarelli joined #xwiki at 18:11
DV joined #xwiki at 18:12
jvelociter - (18:14): I think I'll need some assistance from a rendering wizzard
jvelociter - (18:15): when I write http://pastebin.com/XZeDhgTt
jvelociter - (18:15): the only column is a standalone direct children of the section macro
jvelociter - (18:17): and if I write http://pastebin.com/eQBtZBU4
jvelociter - (18:18): I have a paragraph as direct children of section, then a macro block, followed by a new line block, then followed by the second macro block
jvelociter - (18:19): Is this the expected result ?
lucaa - (18:19): well I guess wjhat you want is 2 columns in a section, right?
lucaa - (18:19): try with an empty line between the 2 column macors
lucaa - (18:20): </guessing>
jvelociter - (18:20): what my macro expected so far, was standalone macro blocks (column) as direct children of the section macro
lucaa - (18:20): ok, then try with the empty line
jvelociter - (18:21): now I have a paragraph that comes in-between, so the macro fails
jvelociter - (18:21): right, it works
jvelociter - (18:21): cool
lucaa - (18:21): they're not standalone as you pasted because you need an empty line to say that the first unit ends, imagine they were 2 paragraphs, you'd need to have an empty line in between
jvelociter - (18:22): yep I think I get it
lucaa - (18:22): I know it's hard :)
lucaa - (18:22): (I was as lost myself too)
npm joined #xwiki at 18:24
jvelociter - (18:32): hmm. should the new lines be needed after a block that is at the end of the document to make it standalone ?
jvelociter - (18:32): If I have {{/section}}\n -> it's inline
jvelociter - (18:32): I need {{/section}}\n\n
jvelociter - (18:32): to have it standalone, when at the end of the doc
jvelociter - (18:32): it feels weird
jvelociter - (18:32): (vmassol lucaa )
vmassol - (18:33): anthing that doesn't have 2 NL is inline
lucaa - (18:33): it only depends what's before him
lucaa - (18:33): it
vmassol - (18:33): (2 consecutive NLs that is)
vmassol - (18:33): it's a pretty simple rule actually :)
jvelociter - (18:33): yes the rule is simple
jvelociter - (18:34): just feels a bit odd at the end of the doc, but that's probably some getting use to needed
vmassol - (18:34): oh the end of the doc is causing pb?
vmassol - (18:34): if you have:
jvelociter - (18:34): no, it works, but it feels odd to be forced to have 2 NL when at the end of the doc
lucaa - (18:34): well the end of the doc should be a bug. What's before the macro?
vmassol - (18:34): this is a bug for me
vmassol - (18:34): if the following doesn't work it's a bug for me
jvelociter - (18:34): yes, it feels like a bug
vmassol - (18:35): NL + NL + {{macro/}} + EOF
vmassol - (18:35): in this ex the macro is standalone
jvelociter - (18:35): yes that's what I have
vmassol - (18:35): now for NL + NL + {{macro/}} + NL + EOF is questionable
vmassol - (18:35): tmortagne: ping
jvelociter - (18:36): test a wait
vmassol - (18:36): (he's in a meeting)
jvelociter - (18:36): I have a NL before EOF indeed
jvelociter - (18:36): let me test w/o
vmassol - (18:36): we can ask him when h'es back
jvelociter - (18:36): yers he's busy, I have him on the screen :D
vmassol - (18:36): :)
jvelociter - (18:37): vmassol: OK with NL before EOF it works fine
jvelociter - (18:37): it makes sense actually
vmassol - (18:37): err?
jvelociter - (18:38): I don't think one NL then EOF should be correct
vmassol - (18:38): with no new line you mean?
jvelociter - (18:38): s/with/without/
jvelociter - (18:38): yes
vmassol - (18:38): ok
vmassol - (18:38): indeed
lucaa - (18:38): huh?
vmassol - (18:38): it's still questionable I think
vmassol - (18:38): we need to check with thomas to be sure that's what we wantr
vmassol - (18:38): want
jvelociter - (18:38): yes the thing is leaving one NL is a natural thing
sdumitriu - (18:38): IMO, the syntax is getting too fragile
lucaa - (18:39): you mean I need to do
lucaa - (18:39): {{thml}}myhtml{{/html}}NL EOF to have that html as standalone?
vmassol - (18:39): it's **always** been like this
vmassol - (18:39): it has not changed a bit
vmassol - (18:39): (in xwiki/2.0 that is)
sdumitriu - (18:39): Then why is it that I've seen tens of commits with "bad usage of macros"?
vmassol - (18:40): because all code was buggy
sdumitriu - (18:40): Nobody really knowh how to write a "good" usage of macro?
vmassol - (18:40): if you look at the syntax definition
vmassol - (18:40): it has not changed at all
vmassol - (18:40): I don't agree with you sergiu
sdumitriu - (18:40): If not even we, hard core developers, know how to use a macro, how can we expect simple users to know this?
vmassol - (18:40): sdumitriu: it's been "fragile" the moment we decided NL are significant
vmassol - (18:41): all this is only the consequence
vmassol - (18:41): and I still think significant NL is good
lucaa - (18:42): vmassol: you have to admit it's a bit strange we have to explain this new line thingy to all developers trying to write a macro, though we believe we know our syntax
lucaa - (18:42): it might be that because of the bug we got bad habits, but it's still strange
vmassol - (18:42): lucaa: developers are the worse kind
vmassol - (18:42): :)
vmassol - (18:42): they never read doc
vmassol - (18:42): if you read the syntax doc you should know ;)
lucaa - (18:42): I know the syntax, that is why I understand what needs to be done when I'm being explained
vmassol - (18:43): the only reason it's complex
vmassol - (18:43): is because we want to be able to enter all use cases
vmassol - (18:43): if for ex we say that we never want two inline macros following each other
vmassol - (18:43): then it's easy to cut corners
vmassol - (18:43): but I can bet you we'll want it
lucaa - (18:43): which is why sergiu calls it fragile: it's complex with hard rules, which makes mistakes easy to make
vmassol - (18:43): no
vmassol - (18:44): the rule is SIMPL
lucaa - (18:44): the good part is that we have a good wysiwyg :)
vmassol - (18:44): it cannot be more simple
vmassol - (18:44): syntax 1.0 rules were hard
vmassol - (18:44): but 2.0 rules are simple
vmassol - (18:44): repeat after me!
vmassol - (18:44): :)
vmassol - (18:44): the only pb is that people are not logical
vmassol - (18:44): so they can't apply a simple rule
vmassol - (18:44): but it's hard to fix this
vmassol - (18:44): anyway
lucaa - (18:45): vmassol: we're talking about myself and jvelociter now
lucaa - (18:45): who couldn't understand how this works
vmassol - (18:45): if one of you has a solution please let me know
jvelociter - (18:45): lol vmassol
lucaa - (18:45): from the jira issue
vmassol - (18:45): lucaa: it's only because you got a bad habit
vmassol - (18:45): IMO
vmassol - (18:45): dunno why you got that habit btw :)
vmassol - (18:46): the syntax is fragile indeed int he sense
vmassol - (18:46): that every NL counts
sdumitriu - (18:46): Maybe it was a bug, but I couldn't make out a logical rule for WHEN is a macro considered inline and when not
jvelociter - (18:46): well I think the rules are simple, but not easy to guess
jvelociter - (18:46): once you know them it's ok
vmassol - (18:46): but that's the choice we made
vmassol - (18:46): we cannot change it
vmassol - (18:46): sdumitriu: it's simple
vmassol - (18:46): 2 consecutive NLs makes stuff standalone
vmassol - (18:46): that's all there is
sdumitriu - (18:47): A velocity macro was considered inline or block depending on some content it had inside, not related to newlines before or after
vmassol - (18:47): nope
vmassol - (18:47): never
sdumitriu - (18:47): EVER
sdumitriu - (18:47): It happened to me more than once
vmassol - (18:47): that would be simply impossible to implement
sdumitriu - (18:47): I know
sdumitriu - (18:47): It's illogical
sdumitriu - (18:47): But it happens
vmassol - (18:47): it's impossible to write a XDOM parser with that
sdumitriu - (18:47): As I said, "Maybe it was a bug"
vmassol - (18:47): yes
vmassol - (18:48): we actually raised it from the beginning
vmassol - (18:48): but the pb is that neither thomas nor I were good enough at javacc to fix it
vmassol - (18:48): and andreas rewrote our javacc grammar thus fixing the bug
vmassol - (18:48): so the real issue is that we waited too much to fix this
sdumitriu - (18:48): And it was completely illogical, replacing the order of the #if #else branches solved the problem
sdumitriu - (18:49): Which didn't actually change anything in the output, except that an extra paragraph was generated around the velocity output
vmassol - (18:50): but
vmassol - (18:50): normally, even before, you should always have put 2 NLs to make macros standalone
sdumitriu - (18:50): So, when logic fails, what was a simple developer like me to do? Apply some random changes until it works, and leave it like that
vmassol - (18:50): the issue was when people didn't the second macro (after the single NL) was considered standalone
lucaa - (18:50): sdumitriu: read the doc, find the bug (anormal behaviour), report it, workaround it
lucaa - (18:50): but that's a problem of time
sdumitriu - (18:51): Yes, I did forward the problem to Thomas, but stuff needed to be done
tmortagne - (19:11): jvelociter: you don't need to have two NL after a macro, just put nothing after a macro
tmortagne - (19:11): if it's at the end of the content
jvelociter - (19:11): tmortagne: yes seen
vmassol - (19:11): tmortagne: the question
vmassol - (19:11): is
vmassol - (19:11): {{macro/}} + NL + EOF
vmassol - (19:12): in this case IMO the macro should be considered standalone
vmassol - (19:12): (assuming there are 2 NLs before it)
tmortagne - (19:12): vmassol: as you said yourself new line are content, the block is not broken because there is only one NL so your have a NEWLINE, it's working excatly the same with
tmortagne - (19:12): paragraph<NL>
tmortagne - (19:12): it has nothing to do with macros
vmassol - (19:12): I know but the end of the doc is special
vmassol - (19:13): we could make it a bit easier for users
tmortagne - (19:13): you just explain that we used simple rules that are the same for everything and now you propose we introduce a special case for macros ?
vmassol - (19:13): since I doubt there are use cases when {{macro/}} + NL + EOF should be considered inline
vmassol - (19:14): tmortagne: it's not for macros actually
vmassol - (19:14): didn't we use to strip NL at beignning and end of doc?
vmassol - (19:14): was this modified too?
tmortagne - (19:15): no whe never did that, wikimodel commons strop first two NL
tmortagne - (19:15): but not the end
tmortagne - (19:16): s/strop/strip/
tmortagne - (19:18): (but that strip first new lines is wrong IMO)
vmassol - (19:18): brb
vmassol left at 19:18 (Quit: Leaving.
vmassol joined #xwiki at 19:19
mflorea left at 19:19 (Quit: Leaving.
DV left at 19:20 (Read error: Connection reset by peer
vmassol - (19:21): back
vmassol - (19:21): personally I'm fine with simple rule
vmassol - (19:21): we can wait and see if we get remarks from users
DV joined #xwiki at 19:21
vmassol - (19:21): jvelociter: wdyt?
vmassol - (19:21): (since you were the one to raise it)
jvelociter - (19:22): I understand tmortagne point of not having an exception for that case
jvdrean1 - (19:23): We've received a new variant for the 19/ proposal for the logo challenge
jvdrean1 - (19:23): http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallenge/planchelogosOKvect4.jpg
tmortagne - (19:23): vmassol: now this rule is written nowhere and the xwiki/2.0 renderer use paragraph\\ (to support all cases like when there is a paragraph after this paragraph ending with a newline)
jvdrean1 - (19:23): I'd like to add it to the page and send an email, WDYT ?
jvelociter - (19:23): in my opinion it's OK to have this behavior, but I start thinking we should have a special "new line behavior summary" documentation page, intended mainly to developers
jvelociter - (19:24): (by this behavior I mean that we don't tolerate one single NL then EOF as standalone block)
tmortagne - (19:24): jvelociter: add a newline handling section in the XWikiSyntax page ?
jvelociter - (19:25): yes for example
jvelociter - (19:25): maybe a distinct page and a include from xwikisyntax could be good too, wdyt ?
jvelociter - (19:25): both would be fine in my opinion
tmortagne - (19:25): yes make sense to have explicit example even if the rule is simple to make sure common uses cases are covered
tmortagne - (19:26): (in any case whatever the place +1 for this section)
jvelociter - (19:26): great
vmassol - (19:26): I think there's a NL section already
vmassol - (19:26): let me chec
vmassol - (19:26): k
jvelociter - (19:26): got to go now, bbl
vmassol - (19:26): http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HNewLineLinebreaks
vmassol - (19:27): we can enrich it a bit more
tmortagne - (19:27): yes there is nothing about inline/standalone
vmassol - (19:28): right this should be added
vmassol - (19:28): there's only for paragrpahs actually
tmortagne - (19:28): there is some in http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HParagraphs
vmassol - (19:29): yes and this need to be generalized
tmortagne - (19:29): yep
tmortagne - (19:30): we don't speak about inline/standalone in the macro section at all
tmortagne - (19:31): have to go
jvdrean1 left at 19:31 (Quit: Leaving.
tmortagne left at 19:31 (Quit: Leaving.
lucaa left #xwiki at 19:37
plunden left at 19:38 (Ping timeout: 248 seconds
arkub left at 19:52 (Ping timeout: 246 seconds
arkub joined #xwiki at 19:53
sdumitriu left at 19:58 (Ping timeout: 265 seconds
nuvolari joined #xwiki at 20:19
nuvolari - (20:19): :>
DV left at 20:34 (Read error: Connection reset by peer
DV joined #xwiki at 20:35
sdumitriu joined #xwiki at 20:38
arkub left at 20:50 (Ping timeout: 258 seconds
DV left at 21:17 (Read error: Connection reset by peer
DV joined #xwiki at 21:17
gvallarelli left at 21:26 (Remote host closed the connection
lucaa joined #xwiki at 21:32
mflorea joined #xwiki at 21:34
DV left at 22:01 (Read error: Connection reset by peer
DV joined #xwiki at 22:01
plunden joined #xwiki at 22:13
CalebJamesDeLisl - (22:24): I agree with sdumitriu, maybe the \n macro behavior was a bug but if it breaks XE in 20 places then it's going to wreak havoc on everyone who upgrades.
vmassol - (22:26): what's your conclusion?
CalebJamesDeLisl - (22:26): It's tough, but I would be thinking about a config parameter.
vmassol - (22:26): ah no please
sdumitriu - (22:26): No
sdumitriu - (22:27): It's painful, but we have to live with our mistakes
CalebJamesDeLisl - (22:27): and the users?
vmassol - (22:27): there are about 30 known bugs in the rendering
vmassol - (22:28): I don't think we shouldn't fix them because some people may be relying on them
vmassol - (22:28): (or have found workarounds)
vmassol - (22:28): if someone is using:
vmassol - (22:28): {{macro/}}{{macro2/}}
vmassol - (22:28): and consider the second macro as standalone
vmassol - (22:28): then obviously that person is making a mistake
CalebJamesDeLisl - (22:29): I guess it's a question of "do we trust the behavior or the documentation?"
CalebJamesDeLisl - (22:30): Maybe we could do a searchDocuments on xwiki.org or each of the subwikis on myxwiki and see how much will be changed.
vmassol - (22:30): it's not representative
vmassol - (22:30): if you have a document wiki then it's not going to be a pb
DV left at 22:30 (Read error: Connection reset by peer
vmassol - (22:30): if your wiki is full of applications in 2.0 syntax you' re likely to have the pb in some pages
vmassol - (22:31): see the changes we've made to the default XE XAR
vmassol - (22:31): AFAICS thomas fixed about 10 places
vmassol - (22:31): (roughly)
vmassol - (22:31): so yes
vmassol - (22:31): it'll cause pb
CalebJamesDeLisl - (22:31): I still have to fix Registration, it didn't throw an error but the behavior is wrong.
vmassol - (22:31): but no I don't agree we should refrain from doing it
vmassol - (22:32): even if it's painful and we'll suffer on the list for a while
CalebJamesDeLisl - (22:33): I think where we suffer is that people learn not to upgrade.
CalebJamesDeLisl - (22:33): Ancient security issues remain exposed forever.
vmassol - (22:33): yes upgrades are painful and will continue to be till we have automated upgrades for documents
CalebJamesDeLisl - (22:34): Like modifying the documents to add the \n if there is one above?
vmassol - (22:34): I was talking generally
vmassol - (22:35): we cannot do what you suggest
vmassol - (22:35): it's impossible
CalebJamesDeLisl - (22:35): I can imagine a change like that causing a lot of it's own trouble.
vmassol - (22:35): it's simply impossible from a logical POV
vmassol - (22:36): (well not impossible but real hard - you'd need to have the 2 rendering engine running side by side, check the output of each and if there's a difference, make the change… ;))
vmassol - (22:37): (and that's discarding other fixes that we have fixed since the last releases....)
vmassol - (22:37): (so close to impossible)
CalebJamesDeLisl - (22:37): So it's not as easy as checking for a \n above the macro.
vmassol - (22:37): errr?
CalebJamesDeLisl - (22:38): I guess that's a no.
vmassol - (22:38): how do you put 2 inline macros separated by NL ?
jvdrean joined #xwiki at 22:38
vmassol - (22:38): if you add another NL then you get 2 standalone macros
vmassol - (22:38): very different
vmassol - (22:39): to summarize: you can't guess what was on the mind of the user
CalebJamesDeLisl - (22:39): I guess I was thinking look for \n\n{{mcaro}}......{{/macro}}\n[^\n]
mflorea left at 22:39 (Quit: Leaving.
CalebJamesDeLisl - (22:40): But that will of course break other things if it is modified.
vmassol - (22:40): yes
CalebJamesDeLisl - (22:40): Something I admire about MS is that they have a 20 year old API which remains unbroken (dos programs still run) I think it has been the key to their success.
vmassol - (22:40): that's easy to do
vmassol - (22:40): provided you want a suboptimal system in the end
vmassol - (22:40): I personally don't admire that
vmassol - (22:41): you just need to keep adding stuff on top of exsiting stuff
CalebJamesDeLisl - (22:41): Of course to get there it is horrible, I imagine there is still dos inside of win7.
vmassol - (22:41): never modify existing stuff
vmassol - (22:41): like:
vmassol - (22:41): rename()
vmassol - (22:41): then
vmassol - (22:41): rename2()
vmassol - (22:41): rename3()
vmassol - (22:41): etc
vmassol - (22:41): if you've coded with MS api you'll know what I mean
vmassol - (22:41): ;)
CalebJamesDeLisl - (22:42): I have never looked at it but I can only imagine.
vmassol - (22:42): success or downfall?
vmassol - (22:42): when your system get heavy you can't innovate anymore
vmassol - (22:42): and you slow down
CalebJamesDeLisl - (22:43): Well, I think their downfall is that they are forcing the vista kernel on everyone (now through win7)
CalebJamesDeLisl - (22:43): So everyone keeps XP which is funny.
vmassol - (22:44): btw this is why xwiki dev is slow to improve
vmassol - (22:44): (on the core side)
vmassol - (22:44): we have a heavy cruft of old things
vmassol - (22:44): that's why we still have important issues that date back from 5 years ago....
vmassol - (22:44): it's just hard to make any modification
vmassol - (22:45): and when you do you break stuff for 4 releases… like 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4 and probably 2.2.5
anamarias joined #xwiki at 22:45
vmassol - (22:45): and that was only a small change
vmassol - (22:46): and it took so many men/days just for it
vmassol - (22:46): so the only soltuino I know in software development
vmassol - (22:46): is to constantly refactor code
CalebJamesDeLisl - (22:46): I agree, and I think it's time to begin thinking about a new api with a focus on security.
vmassol - (22:46): and to do this confidently there's only one solution: a good automated test suite
vmassol - (22:48): for ex that allowed us to completely rewrite the syntax 2.0 parsing a few days ago
vmassol - (22:48): and barely anyone noticed
CalebJamesDeLisl - (22:48): It was completely rewritten?!
vmassol - (22:48): yes
vmassol - (22:48): see, case in point :)
CalebJamesDeLisl - (22:49): And that -broke- changed, the macros/newline issue?
vmassol - (22:49): nope, that fixed it ;)
CalebJamesDeLisl - (22:49): Ok Ok :)
vmassol - (22:49): and tests were broken becuase of it
vmassol - (22:49): so they caught the change
CalebJamesDeLisl - (22:49): Is it faster?
vmassol - (22:50): but since it was a bug, we fixed the tests
vmassol - (22:50): it's supposed to be but since it was alreayd very fast we don't really know yet
vmassol - (22:50): we'd need some specific perf tests to prove it's faster
CalebJamesDeLisl - (22:51): It seems that the page load issue is mainly in the templates now.
vmassol - (22:51): as I said earlier we'd know this rndering bug for ever
vmassol - (22:51): s/know/known/
CalebJamesDeLisl - (22:51): s/page load/page loading speed
vmassol - (22:52): except that we didn't know how to fix it since our javacc knowledge wasn't good enough to fix it
vmassol - (22:52): luckily andreas was an expert in javacc and rewrote the parser for us
CalebJamesDeLisl - (22:52): So the parser is a java compiler?
vmassol - (22:52): so that allowed us to fix about 6 issues quickly
vmassol - (22:53): (that we had postponed for a long tlme)
vmassol - (22:53): this standalone/inline was only one of them
vmassol - (22:53): yes it's a javacc grammar
CalebJamesDeLisl - (22:53): Ok, just read the wiki, "parser generator".
CalebJamesDeLisl - (22:54): This is on the parsing side though right?
CalebJamesDeLisl - (22:54): Because my tests showed that most of the expense was in rendering.
vmassol - (22:55): most of the expense?
vmassol - (22:55): most of the expense is in the db
CalebJamesDeLisl - (22:55): Time cost.
vmassol - (22:55): so removing db cost?
CalebJamesDeLisl - (22:56): I remember when writing my doc loader I found the page speed improvements were not that great.
vmassol - (22:56): if you remove db cost then most of the cost is in clientserver communicztion
vmassol - (22:56): (actually that's probably #1)
vmassol - (22:56): (db being second)
CalebJamesDeLisl - (22:56): However it was more of a dumptruck than a racecar.
vmassol - (22:57): skin displaying is the main cost I think
vmassol - (22:57): but maybe because of client/server comm
vmassol - (22:57): anyway
CalebJamesDeLisl - (22:57): I was discounting the js and css load time.
vmassol - (22:58): I doubt code in xwiki-rendering cost much in the general request processing
CalebJamesDeLisl - (22:59): 1.08 seconds for loading the html. Not too bad.
vmassol - (22:59): and IMO it's definitely not the place to look for for perf improvements
vmassol - (22:59): we need to fix DB, client/server comm, object scaling, etc
vmassol - (22:59): these are the low hanging fruits
CalebJamesDeLisl - (23:00): Or use a cache to hide the issue :)
vmassol - (23:00): caches are not so easy in dynamic systems
vmassol - (23:00): you loose features
CalebJamesDeLisl - (23:00): Really combining the js is the cheapest IMO, but I would like to see xwiki-action working first.
vmassol - (23:00): it's impossible to know the graph of changes
CalebJamesDeLisl - (23:01): Graph of changes? like page load statistics?
vmassol - (23:01): for a given page
vmassol - (23:01): you can't know if a change in another page affects it or ot
vmassol - (23:01): s/ot/not/
vmassol - (23:02): there are too many ways they can affect each other
CalebJamesDeLisl - (23:02): Yes, so you use a short cache time and fake it ;)
vmassol - (23:02): yes but you loose the biggest feature
vmassol - (23:02): freshness of information
vmassol - (23:03): it's not the real soltuion
vmassol - (23:03): it's a poor-man's solution
CalebJamesDeLisl - (23:03): If the cache loads the page from the core after serving the request then it always seems fast but stays (near) up to date.
vmassol - (23:03): since it's only going to work for a small portion of use cases
vmassol - (23:03): near is not good enough for lots of cases
vmassol - (23:03): so you can't consider it a general solution
CalebJamesDeLisl - (23:03): I agree it is a hack, but for people who are just going to use nginx it is a useful hack.
vmassol - (23:04): it's ok for static web sites
vmassol - (23:04): but not for a dynamic system like xwiki
vmassol - (23:04): unless you use it as a static site
vmassol - (23:04): but then you loose its advantage
CalebJamesDeLisl - (23:05): Well I don't see harm in xwiki.org (for example) having a 3 minute delay for guest users.
CalebJamesDeLisl - (23:05): (pages 3 minutes old)
vmassol - (23:05): it's a pb in some parts of xwiki.org
vmassol - (23:05): not for static pages
vmassol - (23:05): but for dynamic ones it is
CalebJamesDeLisl - (23:06): Like the search app?
vmassol - (23:06): the only good solution is what we have in 1.0
vmassol - (23:06): you leave it to the user to decide what to cache
vmassol - (23:06): he's the only one who can know that
vmassol - (23:06): (know for sure that is)
CalebJamesDeLisl - (23:07): +1 but I'd like to extend the user's ability to cache the templates as well if they should so choose.
CalebJamesDeLisl - (23:07): templates meaning the panels, top bar, etc.
CalebJamesDeLisl - (23:08): But I don't think we should worry about speed much until the security is bulletproof.
vmassol - (23:08): I don't agree
vmassol - (23:08): for me the most important is refactoring to introduce new architecutre first
vmassol - (23:09): and to build on that
vmassol - (23:09): for ex template system is bad and old
vmassol - (23:09): and should be redesigned
CalebJamesDeLisl - (23:09): Is the new architecture outlined on a design page?
vmassol - (23:09): no
vmassol - (23:09): not for templates
vmassol - (23:09): well
vmassol - (23:10): it was part of the plans for the new rendering arhcitecture
vmassol - (23:10): but not defined precisely
vmassol - (23:10): so no, nobody has started tackling this yet
CalebJamesDeLisl - (23:11): Here's a problem I see, every line of code in platform is able to access HibernateStore.
CalebJamesDeLisl - (23:11): Any security bug anywhere == database access.
CalebJamesDeLisl - (23:12): After reading DJ Bernstein's paper I am now an even bigger fan of sandboxing :)
vmassol - (23:12): sandboxing is not the isseu IMO
vmassol - (23:12): it's where you define the sandbox's boundaries
vmassol - (23:13): we are already sandboxed
CalebJamesDeLisl - (23:13): In the vm?
vmassol - (23:13): (since we don't allow code to call the DB directly)
vmassol - (23:13): yes that too but that's a different level
CalebJamesDeLisl - (23:14): Can't call the DB directly?
vmassol - (23:14): you have to go through HibenrateStore
CalebJamesDeLisl - (23:14): You mean code can't get hold of the jdbc connection?
vmassol - (23:14): well you can but it's not done anywhere, and it would be easy to prevent physically
vmassol - (23:14): right now it's done by best practices
vmassol - (23:15): (fy the way I've done it in the past was by writing a build time check as pattern test written in aspectj)
vmassol - (23:15): s/fy/fyi/
CalebJamesDeLisl - (23:16): I wonder if code flaws can be exploited and made to do such a thing?
vmassol - (23:17): it's not possible for a generic coding platform to guarantee anything like that
vmassol - (23:17): it would mean removing features
vmassol - (23:17): so it woudn't be a generic platform
CalebJamesDeLisl - (23:17): Clearly the script engines need to be separated from the store because they can be easily made to get the jdbc.
vmassol - (23:18): what if I want to write a macro that access the db through jdbc?
CalebJamesDeLisl - (23:18): Should that be allowed?
vmassol - (23:18): for a generic platform yes of course
vmassol - (23:18): I know lots of use cases for this$
vmassol - (23:19): we can't control security on behalf of developers
vmassol - (23:19): developers that develop on top of the xwiki platform
vmassol - (23:19): all we can control is what we write and provide
CalebJamesDeLisl - (23:19): So maybe code which has PR should be able to run in the same place as the HibernateStore.
CalebJamesDeLisl - (23:20): I think it would be nice to see code separated into two groups: "code which helps the user" and "code which protects the system from the user"
CalebJamesDeLisl - (23:20): code which protects the system == Storage, Authentication, and Rights.
vmassol - (23:20): we had discussed a bit the notion of trusted code
vmassol - (23:21): for me trusted code = code that is located in WEB-INF/lib
CalebJamesDeLisl - (23:21): Everything.
CalebJamesDeLisl - (23:22): My thinking is that we should trust as little as possible.
vmassol - (23:22): I don't like this too much
vmassol - (23:22): since this leads to bloated code in general
vmassol - (23:22): slow and bloated
vmassol - (23:22): since every single method will perform rechecks
vmassol - (23:23): I prefer to defined a safe zone
CalebJamesDeLisl - (23:23): Safe meaning trusted?
vmassol - (23:23): the best safe zone we have is java server code in web-inf/lib
vmassol - (23:23): since this has to be manually installed
vmassol - (23:23): you need access to the server
CalebJamesDeLisl - (23:23): Then where do we put java code which is not to be considered safe?
vmassol - (23:23): physical access
vmassol - (23:23): these are extensions
vmassol - (23:24): loaded from our extension repository by using the extension manager
CalebJamesDeLisl - (23:24): I see. This makes sense.
vmassol - (23:24): it's basically the same as our velocity api
vmassol - (23:24): this is where security checks happen
vmassol - (23:25): it's when "external code" calls "inner code"
vmassol - (23:25): (ie safe zone code)
vmassol - (23:25): this allows all checks to be done at one level and not done and redone everywhere
CalebJamesDeLisl - (23:26): Another way to achieve this is by having trusted and untrusted threads.
vmassol - (23:26): yes
vmassol - (23:26): that could an extension mechanism
vmassol - (23:26): to allow external code the same privileges as trusted code
vmassol - (23:26): (ie safe zone code)
vmassol - (23:27): by using signatures for ex
CalebJamesDeLisl - (23:27): What I like about threads is that if we are careful then the admin may choose to put them is seperate vm's
CalebJamesDeLisl - (23:27): Or on seperate machines if they like.
vmassol - (23:27): how do you do inter thread communication?
vmassol - (23:27): that's awfully slow
CalebJamesDeLisl - (23:28): I don't think it has to be slow.
vmassol - (23:29): inter process is always slow except when you use shared memory
CalebJamesDeLisl - (23:29): Well there is stdin and stdout, but I think it makes more sense to use http connections.
vmassol - (23:29): wow that's definitely slow
vmassol - (23:29): about 100000 times slower than code running at the same place
CalebJamesDeLisl - (23:30): Well you can keep a connection open over time.
vmassol - (23:30): (potentially missing some zeros... ;))
vmassol - (23:30): it's still 1000000 times slower
CalebJamesDeLisl - (23:30): Isn't that how the db connection works?
vmassol - (23:30): yes that's why DB connection is very very slow
vmassol - (23:31): and that's why you always want to reduce requests to the db
vmassol - (23:31): and that's why you always end up introducing caches
vmassol - (23:31): second level cache, etc
CalebJamesDeLisl - (23:31): So that's why I had better luck with fewer queries.
CalebJamesDeLisl - (23:31): (document loader)
vmassol - (23:31): try something
vmassol - (23:31): turn on hibernate request loading for xwiki
vmassol - (23:32): and see how many requetss are sent to the db
vmassol - (23:32): you'll be amazed
vmassol - (23:32): there are hundreds for a single request
CalebJamesDeLisl - (23:32): s/loading/logging?
vmassol - (23:32): logging
vmassol - (23:32): yes
CalebJamesDeLisl - (23:32): Yes I have postgres doing logging, it's ugly
vmassol - (23:32): when I was coding performant systems in the past we were reducing to 2-3 request to the DB max per request
vmassol - (23:33): and that allowed us to scale to 700TPS on transcational systems
vmassol - (23:33): (in test labs)
CalebJamesDeLisl - (23:33): That's mostly rights checking am I wrong?
vmassol - (23:33): don'tknow, maybe
CalebJamesDeLisl - (23:34): One thing I think would speed up the system (for 2.0 api) is to have getObjects(List<EntityReference>)
vmassol - (23:34): object hanlding needs to be reworked yes
CalebJamesDeLisl - (23:34): So lots of things can be loaded at once (one query)
CalebJamesDeLisl - (23:36): One thing I liked about Bernstein's paper was the concept that all code contains bugs and some are security issues so making the smallest amount of trusted code is the best.
vmassol - (23:36): I think you need to take that with a pinch of salt
vmassol - (23:37): it's not the same thing to develop code that controls a space shuttle
vmassol - (23:37): and code that controls editing a wiki document
vmassol - (23:37): becauase there's an associated cost
CalebJamesDeLisl - (23:38): But I see no reason why code that controls editing a wiki document should be allowed to access the database.
CalebJamesDeLisl - (23:38): Perhaps if we sandbox everything then one day they will use it on the shuttle ;)
vmassol - (23:39): it's not whether we want it again
vmassol - (23:39): it's the cost associated
vmassol - (23:39): we should do things that don't cost much and provide good enough securiyt
vmassol - (23:40): but no need for ex to develop 3 versions of xwiki
CalebJamesDeLisl - (23:40): Well Bernstein seemed to suggest that every function should be a separate process running under a separate user name. I disagree with this level of security.
vmassol - (23:40): and then control the output of the systems that would run in parallel
vmassol - (23:40): to veirfy they reutrn the same result
vmassol - (23:40): and if not, throw an error
CalebJamesDeLisl - (23:40): Like a raid device :)
vmassol - (23:41): like software in airplanes
CalebJamesDeLisl - (23:41): Sure, but I think it would be easier to use signatures and checksums and if something failed then try again.
vmassol - (23:42): right now we have a simpler solution to this
vmassol - (23:43): safe code needs to be installed through physical access to the server
CalebJamesDeLisl - (23:43): But on the topic of sandboxing, I don't see the threat being that code will be injected into /WEB-INF/lib/ but rather code in there will be exploited to do arbitrary things.
vmassol - (23:43): yes but there's no way to control this
vmassol - (23:43): since it would mean developing bug free software
CalebJamesDeLisl - (23:43): Threads?
vmassol - (23:43): in some specific cases we can try to reduce the risk I agree
vmassol - (23:44): anyway we're talking too generally here....
CalebJamesDeLisl - (23:44): I would like to have a system where bugs in most of the code have no security implications.
vmassol - (23:44): I'm open to anything on my side
vmassol - (23:44): make a proposal
vmassol - (23:44): :)
vmassol - (23:45): if we want to progress on this we need to discuss on something tangible
CalebJamesDeLisl - (23:45): Well I need to work on the idea so it doesn't make XWiki slower than a commidor 64
CalebJamesDeLisl - (23:46): My current thinking is separate into threads, maybe shared memory is necessary, java provides nice synchronization.
vmassol - (23:46): you can look at osgi
vmassol - (23:46): too
CalebJamesDeLisl - (23:46): I will.
vmassol - (23:46): basically each module needs to explicitely declare its dependencies
vmassol - (23:46): otehrwise they're not visible
CalebJamesDeLisl - (23:46): Hmmm +1
CalebJamesDeLisl - (23:47): Still there is the issue of a bad thread overflowing the garbage collector or eating up all of the heap.
CalebJamesDeLisl - (23:48): Overflowing the GC = segfault. http://stackoverflow.com/questions/65200/how-do-you-crash-a-jvm
CalebJamesDeLisl - (23:49): So I think it would be awesome to have the _option_ of running untrusted code in a different vm, different username, different computer.
CalebJamesDeLisl - (23:49): Http connections are slow but if the api is http accessable, then it's available to client side javascript which would be cool.
vmassol - (23:50): well best would be to use oracle's VM
vmassol - (23:50): they had the ability to do this
CalebJamesDeLisl - (23:50): Oracle prevents too much memory allocation.
CalebJamesDeLisl - (23:50): ?
CalebJamesDeLisl - (23:51): Or allows a vm to run in a cluster?
vmassol - (23:51): AFAIR they had the ability to have app server incoming requests to run in their own VM
vmassol - (23:52): basically they could share VM code between sub VMs
vmassol - (23:52): and thus spawn lots of VMs
vmassol - (23:52): VM = JVM
vmassol - (23:52): I dno't recall the details
vmassol - (23:52): but I remember reading a paper on this
CalebJamesDeLisl - (23:52): I'll have to look in to this.
vmassol - (23:53): maybe this: http://download-uk.oracle.com/docs/cd/B14099_14/web.1012/b14032/jvm.htm
CalebJamesDeLisl - (23:53): Do you know how slow stdin/stdout are?
CalebJamesDeLisl - (23:53): probably not windows compatible :(
CalebJamesDeLisl - (23:54): Anyway where my proposal hits a wall is in serializing and unserializing everything all of the time which will take all day.
vmassol - (23:55): marshalling/unmarshalling is costly
vmassol - (23:55): but #1 cost is network
vmassol - (23:55): this is cost #2
CalebJamesDeLisl - (23:55): loopback shouldn't be that expensive right?
vmassol - (23:55): unless you have very specific network
vmassol - (23:56): loopback is expensive I think
vmassol - (23:56): it has to go through the IP layers no?
vmassol - (23:56): anyway not sure here
vmassol - (23:56): it's been a long time...
CalebJamesDeLisl - (23:56): I have to read up on it.
vmassol - (23:56): anyway it seems to me this is a bit beyond xwiki
vmassol - (23:57): looks like some research project :)
CalebJamesDeLisl - (23:57): It's true we are trying to fix shortcomings of the sun jvm.
vmassol - (23:58): yes that's what oracle did
vmassol - (23:58): from what I remember
vmassol - (23:58): but I don't know how successful they were
vmassol - (23:58): since we haven't heard too much about it, probably not that successful
vmassol - (23:58): my guess is that perf is bad
vmassol - (23:58): you trade safety for perf
vmassol - (23:58): (probably)
CalebJamesDeLisl - (23:58): I still like the idea of exposing the api to javascript via http.
vmassol - (23:59): sure
vmassol - (23:59): we do that already
vmassol - (23:59): GWT is that AFAIK, no?
vmassol - (23:59): we have a xwiki GWT api already
CalebJamesDeLisl - (23:59): Hmm, must take a look, getDocument would be nice.
CalebJamesDeLisl - (23:59): Then we need a js version of Document.