#foswiki 2013-05-10,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o SvenDowideit [04:27]
........ (idle for 39mn)
ChanServ sets mode: +o CDot [05:06]
....................... (idle for 1h51mn)
ChanServ sets mode: +o MichaelDaum [06:57]
............................... (idle for 2h34mn)
CDotInteresting question; if I have a topic "MyTopic" and I delete it, and then someone else comes along and creates a new "MyTopic", should the new "MyTopic" pick up where the history of the old "MyTopic" left off, or should it start a new history? [09:31]
jastnew history IMO
maybe there was a good reason the topic got deleted
[09:36]
CDotok, I agree. Now, what about attachments?
I attach "animated_kitty.gif" to topic rev 1, then delete it (topic rev 2). Then I add it again (topic rev 3). Are we on kitty rev 1 or kitty rev 2?
and if I view topic rev 1 (?rev=1) should I see the latest kitties, or the ones that died?
[09:46]
.... (idle for 16mn)
jastsame logic IMO
though looking at the topic's history is more complicated
it kind of breaks down a bit with foswiki's data structures
given the proper data structures, you should see the ones that died
kind of hard to represent 'when showing topic rev 1, fetch the deleted attachment from $trash because it's no longer where it used to be'
[10:04]
.... (idle for 16mn)
CDotindeed.
however you have confirmed my thinking; that's what you *should* see. It's just not what you *do* see.
[10:25]
MichaelDaumthe trash could have been emptied meanwhile [10:33]
....... (idle for 30mn)
jastyeah, that's yet another complication [11:03]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/VZVGmA
foswiki/master eafb69e CrawfordCurrie: Item12493: Numerous small niggles in Empty* templates fixed. Removed dead EmptyTag....
[11:12]
***GithubBot has left [11:12]
FoswikiBothttp://foswiki.org/Tasks/Item12493 [ Item12493: Numerous minor problems in Empty* templates ] [11:12]
MichaelDaumfrom what I see moving a topic and its rev means the arent available at the old location, all of the revs
when another object refers to them using their dangling location id, no matter whether the referrer is a top rev itself or not.
we don't guarantee integrity of that kind in foswiki ... let's ignore url rewriting for now
the same argument holds when rendering non-top revs of a topic: if they link to an other object not there anymore, well then there's no way it could be displayed as it once was.
if you followed the route to preserve references, then you'd have to deal with %INCLUDEs as well
that is: an old rev including another old rev topic.
so there are some constraints that have to hold for an old rev to still be display correctly
(a) attachment incl history still at the same location (b) other ingredients still there at the same location (c) same acls on all ingredients (d) same preference settings
in theory it requires a snapshot of all of the wiki to render a non-top revision of a topic like it once was....
or an html snapshot of the page
[11:13]
CDotyes. And a decent store ought to provide that sort of integrity.
The core should not get in the way of the store, though.
actually, I don't think it does. Perhaps Julian's work will show us for sure.
[11:22]
.... (idle for 18mn)
JulianLevensCDot, when I first embarked upon versatile, I believed (erroneously) that foswiki kept snapshot integrity. As I worked the details this was clearly false. It may well be possible to improve the situation, certainly I maintain dangling references and maybe that could be leveraged. Right now I'm focused on implementing the store as defined, and alas this would be scope creep right now [11:41]
CDotunderstood. [11:41]
..... (idle for 20mn)
MichaelDaumJulianLevens, do you use a public branch for versatile store?
just to review a bit
the sooner you get more eyes on your work, the better.
the more it is a kind of big flashy spaceship landing from the outer territories, the worse
for now your work has a bus factor of 1. and you do occasionally cross roads, do you?
[12:01]
JulianLevensMichaelDaum: you've already starred my github branch: https://github.com/Jlevens/VersatileSQLStore [12:17]
MichaelDaumargh but not "watched" [12:18]
jasttoo many types of bookmarks! [12:18]
JulianLevensCorrection your a follower
Correction you are a follower
[12:20]
MichaelDaumnow I am
so basically the work is one big 3k file in https://github.com/Jlevens/VersatileSQLStore/blob/master/VersatileDBIStoreContrib/lib/Foswiki/Store/Versatile.pm
the rest is glue
[12:22]
JulianLevensyep [12:27]
MichaelDaumclearly laid out so to say. like it more than the standard vc-handler-foo-fap maze
though the rest handlers could go into the plugins presumably?
the table creators would love to sit in a maintenance class of their own too. this code is required only occasionally, not on every click, is it?
just my first 2c
I'd move some of the prepare statements out of readTopic and other high voltage code paths
even when using prepare_cached
[12:28]
CDotfor the last time THE VC ZOO IS NOT STANDARD. It's just my way of dealing with the crappy RCS stores.
To see "standard" look at PlainFileStoreContrib
which is as simple as simple gets
[12:38]
JulianLevensThanks for the feedback, I'm aware that some of the code could be better structured, but it's not critical right now. I've half concious that I'd like this to work with different RDBMS eventually and that will require more abstractions, e.g. the table creators may be different per RDBMS [12:41]
MichaelDaumtrue [12:42]
JulianLevensFWIW: I'm playing with MariaDB, which of course is a MySQL fork, nonetheless it's interesting and slightly faster [12:42]
MichaelDaumone other way of thinking is to get some of the code out of sight. once the restUPLOADer is done. move it somewhere else.
btw where is _topicInfo() defined ... can't find it
CDot, about the VZ ZOO. nother argument to contribify all rcs
[12:42]
CDotall done. Just running unit tests. [12:45]
JulianLevensI've already removed the rest uploader, I've grabbed CDot's change_store and hacked it slightly. The intent is to make that a de facto tool to convert between stores
_topicInfo is around line 2656 in my current version
[12:46]
MichaelDaumoh got it [12:47]
JulianLevensNote the use of persistence even across requests [12:48]
MichaelDaumdoes it mean $this->{topicInfo} is persistent accross requests?
these interim caches
can't find deletes in sub finish for these guys
[12:49]
JulianLevensNo deliberately not deleted, but topicinfo cannot be cached persistently alas. Only immutable stuff: the names and fields tables [12:51]
MichaelDaumah okay. well then there's some leackage there?
_topicInfo() checks if they are still in {topicInfo} and updates the hash otherwise
given there are two foswiki backends, they might return different topicInfo as they both cache in memory.
[12:52]
JulianLevensYes, within a request repeated {topicInfo} will be faster. Leakage with persistent cache is inevitable, but that's a trade off
What do you mean two foswiki backends?
[12:56]
MichaelDaumthe webserver spawns multiple foswiki instances ... think fcgi
the number of foswiki backends delimits the max number of parallel requests
for instance, my server currently has got 5 virtualhosts.fcgi
... just to give you an example of which problems might arise wrt persistent objects
5 fcgis .... thats low-medium scale
a single page can trigger a couple of them depending on the amount of ajax involved and thumbnail rest calls being active.
[12:57]
JulianLevensOK, but topicInfo is cleared between requests (well it's supposed to be) [13:01]
MichaelDaumhaven't seen that yet....hmmm [13:01]
JulianLevensI'm aware of this issue, which is why I'm only being persistent with the names and fields table which are immutable by design [13:02]
MichaelDaumokay cool
just was musing about the code while scrolling up and down github
did you intend to write a Prefs class tailored towards versatil store?
[13:02]
JulianLevensYes [13:04]
MichaelDaumfor now Versatil.pm is using the TopicRAM class explicitly in _fixUp_PREFERENCES_andACLs [13:05]
JulianLevensThat's the area of code I'm reading up on to ensure i get it right [13:05]
MichaelDaumyea
anyway. good work. the code looks very nice and clean to read.
[13:06]
JulianLevensI use that explicitly during save to use the existing parsing logic to bake the preferences
Thankshanks
Sorry I've something running in the background making tying fun!
[13:06]
.... (idle for 17mn)
jastadd some remote terminal latency to make it even more fun [13:24]
......... (idle for 41mn)
LynnwoodAnyone have much experience with using gmail for foswiki outgoing emails? I've trying to get it set up but the test fails. I'm using the setup as described in general instructions. e.g. MailMethod Net::SMTP::SSL, MAILHOST smtp.gmail.com:465, full gmail account for Username, password, etc. [14:05]
moritz_hi
is anyone using the caldav plugin?
[14:06]
LynnwoodI've setup the gmail account on my local gmail client and confirmed the account works.
but when i run the email test, i get "ERROR: Can't send mail using Net::SMTP::SSL. Can't connect to 'smtp.gmail.com:465' at /var/www/html/wiki/lib/Foswiki/Net.pm line 598."
i'm kind of at a loss what else to try...
[14:07]
jasthave you checked that the network allows a connection from that host to smtp.gmail.com (port 465)? e.g. using nc with -v [14:12]
FloPriis there a possiblity to fpr notification emails in a certain web?
i tried: /bin/rest/MailerContribPlugin/notify?webs=Sandbox
is get lines like : v
Change to UmstellungTest02 at 2013-05-10T14:34:30Z. New revision is 11 but no mails
[14:18]
....... (idle for 32mn)
CDotmoritz: I set it up when I wrote it, but haven't done much with it since. It mostly just works :-) [14:51]
Lynnwoodjast: i was able to to make connection to gmail via nc [15:05]
.................... (idle for 1h38mn)
***JulianLevens has left [16:43]
.................. (idle for 1h27mn)
GithubBot[foswiki] FoswikiBot pushed 2 new commits to master: http://git.io/AHAYCw
foswiki/master 357780a CrawfordCurrie: Item12494: break RCS out of the core...
foswiki/master 511337c CrawfordCurrie: Item12494: mods for core changes since RCS was moved out...
[18:10]
***GithubBot has left [18:10]
FoswikiBothttp://foswiki.org/Tasks/Item12494 [ Item12494: Break out RCS stores into a stand-alone contrib; include it in the release by default ] [18:10]
.... (idle for 15mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/NmoAbQ
foswiki/master 5e8d20c CrawfordCurrie: Item12493: remove deadwood; add tests to JQuery plugins...
[18:25]
***GithubBot has left [18:25]
FoswikiBothttp://foswiki.org/Tasks/Item12493 [ Item12493: Numerous minor problems in Empty* templates ] [18:25]
.......................... (idle for 2h8mn)
***ChanServ sets mode: +o gac410 [20:33]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)