Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* coblej joins08:16
* dwilcox joins08:33
* dwilcox leaves08:37
* awoods joins08:47
* peichman joins08:56
* whikloj joins09:08
* yamil joins09:18
* dwilcox joins09:26
* bseeger joins09:27
* peichman leaves09:43
* peichman joins
* kefo joins09:50
* coblej leaves09:57
* coblej joins10:00
* bseeger leaves10:13
* bseeger joins10:18
* jrgriffiniii joins10:43
Hello everyone10:44
Pardon the enquiry, but has there been any updates regarding the commitment to maintain https://hub.docker.com/r/yinlinchen/fcrepo4-docker/?
<awoods>jrgriffiniii: not yet... still looking for anyone who is interested.10:46
<jrgriffiniii>awoods: We're quite interested, but I hesistate to commit before directly contacting the current maintainer10:48
awoods: May I update you once I've done so?
<awoods>jrgriffiniii: you know Yinlin, right?
<jrgriffiniii>awoods: Yes, we've had e-mail exchanges in the past10:49
* coblej leaves10:56
* ylchen joins
* apb18 joins10:57
* coblej joins
* ajs6f joins10:59
* ruebot is here
* escowles joins
* ajs6f is here for the first half-hour
* escowles is here11:01
* coblej is here
* whikloj is here11:02
kefo++ even
<bseeger>are there any doctors here?
whikloj: boy that was odd
* dbernstein joins
<whikloj>bseeger: what was odd?11:04
<bseeger>whikloj — your odd/even above. ;)
<whikloj>bseeger: yes my "skill" at typing reveals my lack of...skill11:05
<apb18>awoods: What's the scope of this decision - 4.7.x, 5.x.x?11:06
<ajs6f>It has to be the binary.11:07
Triples like my:description hasSize xxx^^uom:pixels make no sense.
<apb18>It has to be the binary, or a resource that is owl:sameAs it.11:08
<ajs6f>apb18: Yes, but we don't deal in OWL at this layer.
<whikloj>ajs6f/apb18: can we not hang triples on a Non RDF Source right now?
<ajs6f>We don't want to require people to nderstand OWL to use Fedora.
whikloj: We do, now.
whikloj: That is the staus quo.
<whikloj>ajs6f: But we also provide the fcr:metadata to provide contextual information about the binary, yes?11:09
<ajs6f>kefo (I think it was) rightly pointed out that that gets confused with the meaning of <> to be annnoying to clients.
whikloj: The triples in which have the subject that is the binary.
<whikloj>ajs6f: So the best solution is to NOT create the fcr:metadata automatically and make the user create one if they want it, using iana:describes etc?11:11
<ajs6f>whikloj: What? Huh? How did you get there from where we started?
whikloj: I have nothing against that idea, but I don't see how it followed...
<whikloj>ajs6f: My brain works in a helix pattern11:12
<ajs6f>whikloj: Auger her in!
* peichman leaves11:14
<ajs6f>I'd rather break <> than RDF, but I'm not even sure we are breaking <>.
* peichman joins
<ajs6f>We're going to break something.11:15
<escowles>the subject of the triples is the binary, the description URL is different from the binary, the <> operator normally refers to the URL...
so the compromise is to have the <> operator refer to the binary URI, because that is the subject of the triples, even though <> typically refers to the URL being operated on11:16
<ajs6f>This is one example of the problems with two separate resources for descriptions and described.
That was an understandable mistake.
Descriptions are representations.
escowles++ # putting it plainly.11:17
* barmintor joins
<bseeger>whikloj: that's exactly what I was wondering - thanks!
<whikloj>bseeger: we're at the same level, it makes me feel less crazy
<ajs6f>+1 to that. Make <> mean the binary, even tho you can argue that that is wrong.
least surprise.
* acoburn joins11:18
<ajs6f>awoods: You cut out.
<ruebot>oh boy
<ajs6f>He gave up.
I knew he would sooner or later.
Still here.
Well, does anyone object to what awoods was saying and escowles is now saying?11:19
<barmintor>is that in reference to the subject of triples in the describedBy LDP-RS?
<ajs6f>barmintor: yes
<ruebot>barmintor: oh, you're here now?
<barmintor>I am clearly missing something important on this call
<ajs6f>escowles: That's all for the future..
<ruebot>barmintor: ok. i'll continue taking notes.
* awoods talking to myself
<acoburn>HTTP servers ignore fragment URIs11:20
<ruebot>awoods: we miss you.
<acoburn>you'd have to rely on Accept headers
<barmintor>it's difficult for me to make the call every week, so I prefer to hash things like that out in written/asynchrnous forums
<kefo>I think it is the only thing that makes some sense.
<ruebot>barmintor: you were the starmaster
<escowles>barmintor: there was a star next to your name to indicate it was your turn to take notes11:21
<escowles>but in the way of these things, the star slides down until somebody catches it11:22
<kefo>So the proposal is to make the diamond operator an exception when fcr:metadata is the request URI.
<barmintor>kefo: that seems like the way to maximize the amount of out-of-band information required by the client to successfully interact with the resource11:23
<ajs6f>barmintor: What is your suggestion?
There is no "solution".
This is inherent in the use of separate resources.11:24
<barmintor>ajs6f: that it be for the URI resource, unless there's a @base in the request body
<ajs6f>barmintor: Also confusing, as evidenced by the fact that our users are now filing tickets because of that behavior.11:25
<barmintor>I think we should strive to minimize the weirdness of those LDP-RSs
<kefo>The only other solution I've heard that would probably work for 4.7.x would be owl:sameAs. That gets us there semantically.
<ajs6f>barmintor: I think we should get rid of them
<escowles>what i keep coming back to is that if users were to create some other resource in the repository to describe a binary, the subject of those triples wouldn't be the binary11:26
so if we are fine with getting rid of binary descriptions, why not just make the subject of the triples the binary description URL?
<ajs6f>escowles: Right. The separate resource thing just doesn't work over the long term.11:27
<acoburn>escowles: I believe LDP mandates the separate resource thing
<kefo>escowles: I can't figure out how there is another solution, given all the specs involved, other than a fragment URI. It seems like there is only one real possibility, unless ajs6f has something up his sleeve with named graphs.
<ajs6f>escowles: But see above for why we don't use the metadata resource for the triples.
kefo: I do, but it is not _remotely_ ready for prime time.
acoburn: No, it _offers_ the separate resource thing.11:28
<escowles>so the way to reconcile these issues is to have some way (Prefer header?) to indicate you want to GET/PUT/PATCH the description instead of the binary itself?
<escowles>right — binary descriptions are optional
<ajs6f>escowles: mimetype
<escowles>what if the binary is an RDF/XML file?
<ajs6f>escowles: Or just conneg, generally
<barmintor>escowles: you can always not use the <> subject11:29
<escowles>or a sparql-update file?
<ajs6f>escowles: Why would you need to have a separate stand-off RDF description of an RDF resource?
escowles: Not saying you never would, just that these are not giant use cases.
<escowles>ajs6f: i think it's exactly the same use case as describing any other binary — i have this file that i want to store (for whatever reason) and i also have administrative or technical metadata about it, that's not a part of the file but that i want to have associated with it11:30
<ajs6f>escowles: I mean "giant" in the sense that I don't think much of a portion of the user base is doing that.11:31
escowles: Not saying that this other idea is perfect.
escowles: Just that we're giving up something in any direction.
<escowles>ajs6f: that is true
<ajs6f>Got to run. Don't stop having too much fun.11:32
* peichman leaves
* peichman joins
<escowles>i'm increasingly interested in what acoburn mentioned he's doing with trellis: putting binary properties in headers — users can always create other resources to describe binaries if they want to11:33
<barmintor>escowles: that seems like it just reproduces the semantic issue, no?11:34
<acoburn>escowles: barmintor: I'm still using conneg for descriptions of LDP-NRs
<escowles>barmintor: yes, that's the downside — you have to use owl:sameAs or some other mechanism to understand that those triples describe the binary
<whikloj>least bad, the unsuccessful spin-off of breaking bad
<acoburn>it's not ideal, but it seems more consistent11:35
<whikloj>awoods: +1
<escowles>oh, then i guess i'm increasingly interested in my misunderstanding of what acoburn is doing...
<barmintor>acoburn: it creates a problem for hydra installs that sometimes store RDF docs as a binary
acoburn: that's not your problem, but it's a problem for generalizing the approach11:36
awoods: what's that fcr4 demo URL again?
<acoburn>barmintor: in that case, you're claiming a NonRDFSource is actually RDF
barmintor: which is, itself, inconsistent
<barmintor>acoburn: not exactly- you might actually have a RDF serialization as a document
acoburn: we run into this kind of think with some of our digital archives11:37
<acoburn>barmintor: but then you're conflating resource and representation
<barmintor>acoburn: I'm just saying that if a file is an actual ttl document, conneg is a weird place
<apb18>barmintor: acoburn: api-x does that - persists owl ontologies as an LDP-NR, because there is no other way to do it.
<acoburn>barmintor: I completely agree
apb18: is that due to the single-subject rule?11:39
<apb18>acoburn: Also blank nodes, as they have a specific meaning on owl
* ylchen_ joins11:40
<barmintor>escowles: here is the deal I have with that whole ticket:
<acoburn>apb18: but the spec is silent on BNodes, and I wouldn't ever claim that Fedora-on-Modeshape does the right thing with BNodes
<barmintor>escowles: if you look at the returned graph from a binary's description
escowles: it has the subject right there
<escowles>i wonder if we could use mime-type parameters to differentiate between an RDF binary and its description?11:41
<barmintor>escowles: I don't think we're under any obligation to support this jump that <> means the most popular subject in the graph
* ylchen leaves11:42
<ruebot>So, no Schmidt sting pain index?
<escowles>barmintor: quite the contrary, i think the main recommendations are that <> refer to the URL being operated on, as opposed to whatever is in the graph
<barmintor>escowles: I thought the suggestion was that <> be interpreted as the binary URI11:43
<escowles>barmintor: yes, that is what we're going to do — but i think we have to acknowledge that this is a compromise to make the REST API usable....11:44
I think that is the path of pain and regret
<apb18>barmintor: <> is the binary URI for 4.7.x, which is carrying forward a bug for the sake of avoiding breaking changes.
<barmintor>I mean, votes are votes.11:45
apb18: what is the breaking change?
<apb18>Interpreting <> correctly would be a breaking change.11:46
<barmintor>apb18: clearly we are not resolving it that way on PATCH, or we would not have gotten the ticket
I am confused
we are currently correctly resolving <> on PATCH
are we not?11:47
<apb18>Currently, when operating on /fcr:metadata, <> is interpreted as <the binary> for PUT and PATCH, instead of </fcr:metadata> (which would be the correct interpretation)
<bseeger>apb18 - patch doesn't work on a binary11:48
well, refactor and deprecate
<apb18>barmintor: PUT and PATCH on /fcr:metadata
<barmintor>apb18: what is broken in https://jira.duraspace.org/browse/FCREPO-239611:50
<bseeger>no opinion - I have no real experience with it.
<barmintor>apb18: that ticket says that PUT & PATCH act differently
<acoburn>awoods: wouldn't it be possible to move rbacl/xacml into -exts or -labs, and if someone wants to maintain them, they can do that
<whikloj>acoburn: I think that is the procedure right, move to -exts and if we can't find maintainers then it goes to -labs or -archive11:52
<apb18>barmintor: re-reading
<kefo>barmintor: A PUT to fcr:metadata fails. No triples are updated.
<barmintor>kefo: if you use <>, but not if you use your intended subject11:53
<kefo>barmintor: Further discussion uncovered the fact that the diamond <> is not interpreted as the Request URI - fcr:metadata.
<kefo>barmintor: I actually do not know. I've not tested that, come to think of it.11:54
<kefo>barmintor: It is more accurate to say that a PUT to fcr:metadata that uses a diamond operator fails.
<barmintor>kefo: where "fails" := does not add statements about the binary11:55
<kefo>barmintor: Correct.
barmintor: To bring this full circle, a PATCH to fcr:metadata that uses <> will succeed, though the diamond operator is interpreted as the binary's URI, not the Request URI (fcr:metadata).11:58
<bseeger>regarding PUT & PATCH: in case this is helpful for anyone else, here's a gist of PUT and PATCH with binary and fcr:metadata: https://gist.github.com/bseeger/a3ff0bc4fe6c3d445554cc70b25ca79d
* ylchen_ leaves12:01
<escowles>gotta drop off for another call...
<kefo>bseeger: So the "PUT on fcr:metadata" succeeds, but the Request URI is not actually fcr:metadata. It's the binary URI, yes?
* ruebot will be gone next week too
* acoburn leaves
<bseeger>kefo: oh, let me fix that… I was going kind of quick - I'll double check it12:02
<barmintor>bseeger: can you add the content of put.txt to thatgist?12:03
<bseeger>barmintor: sure12:04
<ruebot>awoods: notes are in the wiki12:05
<bseeger>kefo, barmintor: I'm not sure that I'm actually doing the PUT correctly though… I updated what I am seeing.
<bseeger>kefo, barmintor: the curl call for PUT is wrong on my part.
<barmintor>yeah, the PUT works becasue you replaced the binary content with the sparl-update text :)12:07
PUT should be a ttl or json-ld doc
and default to ttl
<bseeger>barmintor: yeah… fixing that now. :) :)
* ylchen joins12:11
* coblej leaves
<escowles>i just rechecked this and here's my script demonstrating that a PUT to the binary description using <> does not work correctly: https://gist.github.com/escowles/c1c4331a2a27b3cf960cf3f2012fa17412:12
* ylchen leaves12:16
<awoods>barmintor: I hear your concern with the approach to warp the meaning of <>. I have not yet heard your alternate recommendation, however. Can you restate that recommendation?12:17
<barmintor>awoods: that PUT requests use the correct subject
awoods: as far as I can tell, PUT to fcr:metadata doesn't work at all12:18
<awoods>barmintor: and that the triples in the rdf-description have a subject of /fcr:metadata ?
<barmintor>awoods: no
awoods: I mean, I'm w/e on that point
<apb18>barmintor, escowles PUT with "<the binary> <predicate> <object>" works OK "<> <predicate> <object>" does not12:19
<awoods>barmintor: what is "the correct subject"?
<barmintor>apb18: I cannot reproduce that, can you gist it?
<apb18>perversely, that's because PUT interprets <> as </fcr:metadata> (i.e. correctly)
<barmintor>apb18: right
<apb18>barmintor sure.. just a sec
<barmintor>apb18 awoods I'm trying to get at what the behavior actually is if we're worried about backwards compatibility12:20
<escowles>barmintor: i've added a second script that works: https://gist.github.com/escowles/c1c4331a2a27b3cf960cf3f2012fa174
<barmintor>escowles: cool, that seems correct. My example must be broken.12:21
<awoods>barmintor: I hear your suggestion to be: interpret <> to be the URI of the target resource (/fcr:metadata), but then translate the subject of the triples to be the binary. Is that what you are say?
<barmintor>awoods: what?
awoods: the subject of the triples is already the binary
<apb18>escowles, barmintor cool, that's what I get too. PUT is interpreting <> as the correct (according to the spec) resource: /fcr:metadata.
it's behaving badly in that it's silently dropping triples that have </fcr:metadata> as a subject12:22
<barmintor>so if PUT seems to be according to spec, what is PATCH doing
<apb18>patch is interpreting <> as <the binary>
so there's no "bug to carry forward" on PUT12:23
<apb18>the "fix" proposed for 4.7.1 is to break PUT to make it consistent with PATCH
<escowles>and since PUTting to <> wouldn't work anyway, it's not a breaking change...
<barmintor>I mean, ok, but that is *also* a backwards incompatible change
<bseeger>how is escowles script acting badly — if <> goes to fcr:metadata, then the 2nd PUT shouldn't work at all
<barmintor>bseeger: the LDPS is allowed to ignore triples12:24
<apb18>barmintor: It's leaving PATCH untouched, but breaking PUT in a way that is already broken, as <> is unusable with PUT at the moment
that didn't come out right..
<barmintor>apb18: right, what I'm saying is that if the argument is "we're doing a bad thing to keep from breaking current behavior" that is not true, it's "we're breaking PUT with a unspecc'd behavior because we want <> to continue to be broken on PATCH"12:25
to be honest I don't even know what AF does, do you escowles ?12:26
does it just always use the diamond subject?
<apb18>barmintor: that's a more clear way to put it; "we're breaking PUT with a unspecc'd behavior because we want <> to continue to be broken on PATCH"
<barmintor>apb18: that might be an economic argument, but it's not a backwards copatibility argument
<escowles>barmintor: i don't know, but i saw some instructions on the hydra slack about dumping the PUT/PATCH bodies being sent to fedora12:27
<barmintor>escowles: like, we don't even know what clients are relying on the broken behavior?
<apb18>Well, the backwards compatibility argument is "don't fix PATCH, since people rely on the way it behaves now"
<barmintor>ruebot: what's the islandora situation?
apb18: people *might* be doing that now12:28
<apb18>barmintor: If people are successfully modifying the contents of /fcr:metadata, they're either using PATCH, or using PUTS with explicit subjects12:29
<barmintor>apb18: but they may not be using PATCH with <>12:30
<awoods>apb18: definitely
<barmintor>apb18: I don't know why they would
<apb18>barmintor that's true, they may not be using <> in patch. Our one data point is that kefo was
<barmintor>apb18: so we may be saying "we're going to break something because a ticket misunderstood how PUT worked"
<kefo>escowles: That was me on hydra slack asking that question.12:31
<barmintor>escowles: I'm looking at https://github.com/projecthydra/active_fedora/blob/a641a8f0d65e7c01f395eeb58c5e87c638395e2e/lib/active_fedora/sparql_insert.rb#L22 and that looks like an explicit subject12:32
<apb18>barmintor: we may be saying that
<barmintor>escowles: but I don't see any test fixtures, so
<kefo>escowles: This isn't quite the forum, but Sufia - and perhaps at the bottom of the stack it is AF - does not update fcr:metadata with PATCHes correctly. That's a report I am still working on. I discovered this Fedora issue trying to find a solution to my Sufia issue.
<barmintor>apb18: that feels like a much different argument, right?
awoods: the HTML UI does not present <> subjects12:33
awoods: PUT is behaving correctly
<escowles>barmintor: AF is doing PATCH with <>: https://gist.github.com/escowles/c1c4331a2a27b3cf960cf3f2012fa17412:34
<awoods>barmintor: yes... by ignoring the triples in the request
<ruebot>barmintor: summary so i don't have to read back scroll?
<apb18>It does. However, it appears that fixing the issue to align with specs generally disliked (although to me it's the most clear)
<bseeger>What's interesting is that if I do a patch (using <>) on /rest/fcr:metadata it works just fine (resolving to /rest) So whatever PUT is doing seems like it might be kinda global.12:35
<kefo>barmintor: PATCH with <> to fcr:metadata succeeds, in that it updates the triples that have the <binary> as subject.
<escowles>ruebot: how does islandora update binary descriptions
<barmintor>awoods: no, I mean PUT is literally working correctly
awoods: it works if you use the binary URI as the subject
<apb18>barmintor: I think it's incorrect in returning a 204 instead of a 409, since it's silently dropping triples when you use <>12:36
* ruebot looks
* ruebot notes dlamb is on vacation this week
<apb18>barmintor: but with respect to <>, it's correct
<kefo>barmintor: To be clear: a PUT to fcr:metadata that explcitly uses <binary> as the subject succeeds. Yes.
<apb18>kefo: yes
kefo: a PUT with subject of <the binary> succeeds
<barmintor>apb18++ // yes, if it won't allow any of those, we should 409 with a constraints doc12:37
<ruebot>escowles, barmintor: looking at the code, i don't think we're there yet. whikloj, that sound right?12:38
<awoods>here is the gist from the fcrepo-2396: https://gist.github.com/kefo/40ddf654ef96edce523b2559dae26c1a
* bseeger leaves
<escowles>ruebot: hooray — it's easy not to break code that's not written yet!
<ruebot>CLAW always wins because we're so far behind :-D12:39
<barmintor>apb18 awoods: http://demo.fcrepo.org:8080/fcrepo/rest/09/1b/c4/fc/091bc4fc-8530-43b1-a33f-8d946f8d1b5b091bc4fc-8530-43b1-a33f-8d946f8d1b5b/c9/ab/f8/cb/c9abf8cb-2b13-4cfb-a5bb-f1a663989b58/fcr:metadata is not in the topic of this RDF, which is http://demo.fcrepo.org:8080/fcrepo/rest/09/1b/c4/fc/091bc4fc-8530-43b1-a33f-8d946f8d1b5b091bc4fc-8530-43b1-a33f-8d946f8d1b5b/c9/ab/f8/cb/c9abf8cb-2b13-4cfb-a5bb-f1a663989b5812:40
that's the 409 I get from explicitly using the /fcr:metadata subject
and that's what we should do for <> subject IMO- resolve them to spec and 40912:41
escowles: where did you get that update doc?
<escowles>barmintor: what update doc? my script just has a triple inline
<barmintor>escowles: the patch body12:42
<escowles>oh, you mean from AF?
<apb18>barmintor: I would totally agree
<escowles>i used these instructions from tpendragon https://project-hydra.slack.com/archives/general/p1487189517001298
<barmintor>apb18: I'm just trying to sort out where we rely on PATCH to the binary descriptions
<escowles>and then fired up rails c and updated an object12:43
<barmintor>escowles: so that's what httplogger dumped?
<whikloj>sorry ruebot I missed the <ping> what are we not there yet?
<escowles>wait, i updated a container, not a binary...
<apb18>barmintor: however, the consensus was the opposite.. that <> should be made to resolve to <the binary> just like PATCH
awoods: I'm not suggesting a veto, but can we have a vote on this in github instead of a roll call?12:44
awoods: or even the committer list?12:45
<whikloj>ruebot/escowles: I found it, Islandora CLAW is not there yet.12:46
<escowles>barmintor: ok, i updated an actual binary this time (not a %!#@$ FileSet) and it uses the full binary URI: https://gist.github.com/escowles/c1c4331a2a27b3cf960cf3f2012fa174#file-patch-binary-body-af-txt12:47
escowles: you are a valiant debugger
<escowles>barmintor: it's what i'm good at12:48
<apb18>FWIW, in local code at JHU, we use the full binary URI in descriptions.
* peichman leaves12:49
* peichman joins
<barmintor>escowles apb18 if I update that ticket with these finding over lunch, will y'all have a chance to verify my summary?
<apb18>barmintor: sure!12:50
<barmintor>apb18++ thank you
<escowles>apb18: yep!12:51
<barmintor>apb18 escowles bseeger kefo awoods thank you for bing so patient with my panicking here
<escowles>barmintor: n/p — i'm not really sure what the right thing to do is here, but i think we're clearly not doing it yet12:52
<apb18>barmintor: It's usually worth the time to sit down and get to the bottom of what's actually going on... and describe it in a way that can be understood!
<kefo>barmintor: No problem. It's very layered this one.
<barmintor>escowles: I am going to propose that the right thing is to have PUT to a binary description with diamond subject return the same error that an explicit subject of the fcr:metadata resource would12:53
escowles: since that change appears to jeopardize no current libraries, and just moves an obscure 204 -> 409 with a clear message12:54
escowles: but I'm also just going to document all this, and ask people to vote
<escowles>barmintor: i agree that it would be an improvement to error here, rather than happily ignoring triples with the <> as the subject
* barmintor shrugs
<apb18>barmintor:... and leave PATCH untouched?
or one step at a time12:55
<barmintor>apb18: right. I think it is worth noting that escowles finds that hydra doesn't use <> in PATCH for the binary descriptions
probably because of a similar issue in the past12:56
and that CLAW doesn't do this yet
* bseeger joins
<ruebot>there is an API-X call today, right?13:00
<apb18>ruebot: yup, dialing
* ruebot me
<barmintor>kefo: your tests indicate that PATCH with <> subjects works, right?13:05
kefo: to the LDP-NR's description?
<kefo>barmintor: yes and yes.13:06
* ddavis joins13:08
* coblej joins13:12
* coblej leaves13:20
* coblej joins
* Ruth_ joins13:24
* ylchen joins13:42
* coblej leaves13:43
* coblej joins13:51
* ylchen leaves13:54
* ylchen joins13:59
* ylchen leaves
<whikloj>apb18/ruebot: are you on the API-X call? I seem to be alone14:02
apb18/ruebot: Oops I got the time wrong14:03
<ruebot>whikloj: :-(
whikloj: i was there though! all good
<apb18>whikloj: I'll put up the minutes later this afternoon!14:04
* dbernstein leaves14:09
* dbernstein joins14:11
* bseeger1 joins14:55
* bseeger leaves14:57
* coblej leaves14:58
* coblej joins
* Ruth_ leaves15:13
* coblej leaves15:24
* coblej joins15:28
* coblej leaves15:32
* coblej joins15:33
* coblej leaves15:47
* coblej joins15:49
* bseeger1 leaves15:55
* coblej leaves
* coblej joins15:57
* coblej leaves16:02
* bseeger joins
* coblej joins16:03
<ruebot>awoods, acoburn: ping16:11
* ajs6f leaves16:14
* coblej leaves16:15
* coblej joins16:16
* ddavis leaves16:23
* awoods on a call16:25
* grosscol joins16:50
* coblej leaves17:12
* grosscol leaves17:14
* bseeger leaves17:17
* dtd34 joins17:34
* dtd34 leaves
* jrgriffiniii leaves17:38
* dwilcox leaves17:41
* peichman leaves17:44
* yamil leaves17:47
* dbernstein leaves17:52
* whikloj leaves18:01
* kefo leaves18:06
* apb18_ joins18:38
* apb18 leaves18:39
* jrgriffiniii joins19:21
* dwilcox joins20:46
* dwilcox leaves21:16
* jrgriffiniii leaves22:14
* awoods leaves23:03

Generated by Sualtam