12:01 <@Crell> OK, let's get started.
12:01 <@Crell> Hi everyone!
12:01 -!- OSInet [~fgm@drupal.org/user/27985/view] has joined #drupal-wscci
12:01 < OSInet> Hi all
12:02 < dixon_> Hi all
12:02 < EclipseGc> Crell: yeah so that's pretty much what I was saying
12:02 <@Crell> Thanks for coming out.  I want to try and blitz through our agenda reasonably quickly in the first hour.  We can continue debating later on, but I am going to try and time box the 3 main items.
12:02 <@Crell> I'm going to assume that people have read the issues and pages lined from http://groups.drupal.org/node/165059 for background.
12:03 <@Crell> Item #1: An HTTP library that doesn't suck: http://drupal.org/node/1178246
12:03 -!- yoroy [~yoroy@j87028.upc-j.chello.nl] has joined #drupal-wscci
12:03 <@Crell> At the moment I think the likely candidates are Zend and Symfony.  Both have the advantage of being well-maintained, PSR-0, PHP 5.3 native, and extremely permissive licenses.
12:03 <@Crell> However, I believe Zend requires a Contributor License Agreement if we want to contribute patches back where Symfony does not.
12:04 < EclipseGc> Symfony is GPL?
12:04 <@Crell> That leans me toward Symfony, although I've not looked at either of them in detail yet.
12:04 <@Crell> EclipseGc: They're both BSD-ish, I believe.  Dries has already said that he's OK with pulling one or the other in if appropriate.
12:04 < EclipseGc> k
12:04 < skwashd> ZF is BSD, and symfony is MIT
12:05 <@Crell> Also relevant is that the CMI initiative may want to borrow one of their YAML or JSON parsers, too, so we're talking to an extent about which major pure-component-framework we want to start leveraging.
12:05 <@Crell> skwashd: Thanks.
12:05 < dmitrig01> What's PSR-0?
12:05 < catch> dmitrig01: class naming/directory convention
12:05 <@Crell> PSR-0 is a growing standard convention for class and namespace naming and usage.
12:05 < skwashd> dmitrig01, http://groups.google.com/group/php-standards/web/psr-0-final-proposal
12:05 < dmitrig01> thanks.
12:06 <@Crell> It has its issues and I don't like all of its components, but it is the closest thing there is to a standard on such things at the moment.
12:06 <@Crell> So, throwing the question out: We need someone to look into these frameworks, and a criteria to give them.
12:06 -!- fago [~fago@chello084112011033.13.11.vie.surfer.at] has joined #drupal-wscci
12:06 <@Crell> Preferably who can do so this week and report back quickly because we want to be able to move forward.
12:06 < neclimdul> Crell: is the PSR-0 bit going to cause trouble with drupal's path standards? I know that was a concern with plugins
12:06 <@Crell> What criteria do we want?
12:06 -!- samkottler [~Adium@ool-18e488a0.dyn.optonline.net] has joined #drupal-wscci
12:07 -!- jeffschuler [~jeff@cpe-107-10-50-17.neo.res.rr.com] has joined #drupal-wscci
12:07 <@Crell> neclimdul: No, because this is stuff that would go in /includes/sf/*stuff*, or /includes/zend/*stuff*.
12:07 < EclipseGc> Crell: can we start with what criteria YOU want? and expand from there?
12:07 <@Crell> EclipseGc: I guess we can.
12:07 < neclimdul> Crell: makes sense. we just wouldn't be extending it outside of core.
12:08 <@Crell> neclimdul: At this point, unlikely.  Although I think migrating most of /includes that stays in /includes to PSR-0 classes is definitely something we should consider.
12:08 < skwashd> Crell, to clarify ... are we talking about ZF1 or ZF2 ?
12:08  * neclimdul nods
12:08 <@Crell> ZF2.
12:08 < skwashd> k
12:08 <@Crell> Things I think we want:
12:08 <@Crell> 1) Secure-by-default (like Drupal).  If it uses ext/filter, so much the better.
12:08 < skwashd> Crell, i can probably drop some other community stuff to do put 15hrs into this over the weekend
12:09 < skwashd> and whatever i can find inbetween client time
12:09 < skwashd> someone just needs to give me a brief :)
12:09 < dixon_> I could help skwashd to write something up
12:09 < OSInet> is it actually http://framework.zend.com/manual/en/zend.http.html ?
12:09 <@Crell> skyred, dixon_ Great!
12:09  * skwashd looks over his shoulder at skyred :)
12:10 <@Crell> Er.  You guys need to get more different names. :-)
12:10 <@Crell> 3) Cleanly extensible, because I know we'll want to do stuff with it and I don't want to touch existing code.
12:10 < dixon_> So, what more criterias are we looking at?
12:10 < EclipseGc> Crell: where was 2)?
12:10 < dixon_> and 2)?
12:10 -!- webchick [~Adium@drupal.org/user/24967/view] has joined #drupal-wscci
12:10 <@Crell> 2) Clean access to all HTTP headers, not just the usual suspects (GET and POST).  We want to be able to act on all kinds of headers.
12:10 < dixon_> hehe
12:10 <@Crell> Bah!
12:10 <@Crell> (I'm copying to another text file at the same time, sorry. <g>)
12:11 < dixon_> Crell: how about the both handling requests both ways?
12:11 < webchick> Aw. My cats didn't wake me up. Sorry!
12:11 -!- a_c_m [~a_c_m@drupal.org/user/195063/view] has joined #drupal-wscci
12:11 < dixon_> or is that more like a bonus?
12:11 < webchick> I'm here now. :)
12:11 < skwashd> i beat skyred on nickserv reg by ~5 years :)
12:11 <@Crell> dixon_: That would be a nice bonus.  I'll add that.
12:12 < dixon_> Crell: ok
12:12 < EclipseGc> webchick: we're just really starting so no worries :-)
12:12 < voxpelli> Crell: You mean raw access to HTTP headers or processed?
12:12 <@Crell> voxpelli: How do those differ?
12:12 < EclipseGc> oh good we have services folks :-D
12:12 < catch> could we announce this in #drupal-contribute ?
12:12 < EclipseGc> I'll announce it
12:12 < EclipseGc> people ignore me
12:12 < EclipseGc> so it'll stay small
12:12 <@Crell> lol
12:12  * catch would have had no idea if it hadn't been mentioned.
12:12 < voxpelli> Crell: Parsing eg. access headers is a science in itself - since HTTP folks wanted to make things crazily hard
12:13 -!- bojanz [~bojanz@drupal.org/user/86106/view] has joined #drupal-wscci
12:13 <@Crell> voxpelli: Hm.  The question there is do we want that parsing in the library, or in the context object, since in practice we want any access to HTTP to probably go through the context object anyway?
12:13 <@Crell> I suppose if the existing parsing is good, that would mean less work for us.
12:14 < EclipseGc> less work ++
12:14 < webchick> catch: please do!
12:14 -!- darthsteven [~darthstev@109.123.86.70] has joined #drupal-wscci
12:14 < webchick> I just twitterererererd it too
12:14 < voxpelli> Crell: We probably need raw access - but parsing of headers would be a nice to have - especially with headers like the access one
12:14 -!- ultimateboy [~Adium@c-67-162-132-95.hsd1.co.comcast.net] has joined #drupal-wscci
12:14 < voxpelli> Crell: as long as we stick to the HTTP spec when interpreting the http specs it's cool
12:14 < dixon_> I guess some parsing needs to be happening if it should be secure by default
12:14 < EclipseGc> voxpelli: would it make sense to just have access to both?
12:15 -!- frega [~chatzilla@p54BD9DF3.dip0.t-ipconnect.de] has joined #drupal-wscci
12:15 < EclipseGc> is that even a valid question?
12:15  * a_c_m got here vial crell's tweat
12:15 -!- arshad [~arshad@197.224.186.164] has joined #drupal-wscci
12:15 <@Crell> https://docs.google.com/document/d/1-K1C8Qp6D3kjwHvPEHS3Lme0LBlIdSCLjeEL8nzAnUA/edit?hl=en_US - I moved my notes to a google doc.
12:15 < catch> this appears to be the Symfony class https://github.com/symfony/HttpFoundation
12:15 < voxpelli> EclipseGc: yes - I think that's required for eg. some auth mechanisms
12:15 <@Crell> catch: Yep, that's one of the ones we want to consider.
12:15 -!- jcfiala [~jcfiala@8.20.208.5] has joined #drupal-wscci
12:15 < EclipseGc> voxpelli: k
12:16 -!- msonnabaum [~msonnabau@pool-173-71-24-164.dllstx.fios.verizon.net] has joined #drupal-wscci
12:16 < voxpelli> EclipseGc: but I'm not sure - we would need to check that - perhaps we should do some parsing always
12:16 < OSInet> AIUI in Symfony2 the raw headers are available as a HeaderBag and the processed ones by getter methods
12:16 < dixon_> maybe voxpelli can join me and skwashd in eveluating some libs with his Services experience?
12:16 < EclipseGc> voxpelli: well, I just mean having raw in one section and "safe" in another
12:16 <@Crell> voxpelli: Go ahead and tweak item 3 in the list in the doc so that it makes sense.
12:16 < skyred> Crell, In HTTP headers, there is also "Extra Headers" fields,  so raw access to Http headers might be necessary
12:16 < EclipseGc> it can occasionally be useful
12:16 < chx> Crell: sorry i got dragged into a call , just read up , note that ext/filter has its own severe issues esp when relating to URL -- we needed to yank out filter validate url in favor of valid_url. That's just a (known) bug with ext/filter but needs to be mentioned.
12:17 <@Crell> chx: Thanks, made a note int he doc.
12:17 < voxpelli> dixon_: I'll have short of time for the rest of the week - and I'm not enough up to date on the HTTP spec
12:18 <@Crell> OK, anything else?
12:19 <@Crell> We have secure by default (caveat for ext/filter and urls), raw HTTP headers, parsed HTTP headers, extensible, and it would be nice if it is proxy-capable.
12:19 <@Crell> Oh, and licensing considerations. :-)
12:19 < EclipseGc> Crell: I think I'd like to hear from the services folks if there's anything in an http library that you haven't mentioned that they'd like to see
12:19 <@Crell> Services folks: Is there?
12:19 < skwashd> Crell, for symfony are we considering https://github.com/symfony/HttpFoundation ?
12:19 <@Crell> skwashd: Yes.
12:19 < catch> I like that Symfony split their classes up.
12:19 < skwashd> nm ... someone else found it
12:19 < hejrocker> voxpelli knows the most about this, unless hugo is around
12:20 < catch> This is going to be a very low level dependency for everything else, so it's nice if the bits we need early bootstrap are fairly lean.
12:20 <@Crell> voxpelli: Anything we're missing?  If not, let's move on.
12:20 < voxpelli> EclipseGc: Crell: We have a library for parsing accept headers now
12:20 -!- gravelpot [~pfg@dhcp-146-6-79-92.ugs.utexas.edu] has joined #drupal-wscci
12:20 < voxpelli> That's why I brought it up - can't think of anything else for now
12:20 < skyred> EclipseGc, Web Services Clients developers might be more demanding than services developers
12:21 < voxpelli> skyred: I highly doubt that ;)
12:21  * Crell snickers.
12:21 < EclipseGc> Crell: if the services folks are happy, I'm happy
12:21 < EclipseGc> :-)
12:21 <@Crell> OK, skwashd and dixon_: Can you guys get us something by this coming weekend?
12:21 < skyred> voxpelli, Crell is Authentication mentioned in HTTP headers?
12:22 < dixon_> Crell: that's a deal!
12:22 < dixon_> :)
12:22 <@Crell> Sold!
12:22 < skwashd> Crell, by the end of it ... sure :)
12:22 < voxpelli> Crell: Btw - Cookie parsing is another example of an advanced header we need to think about
12:22 < EclipseGc> voxpelli: that would make SSO simpler in the long run no?
12:22 <@Crell> Roger.
12:22 <@Crell> OK, moving on to #2.
12:22 < OSInet> one problem i've met when interfacing with MS' client sites was the ability to work over a secure tunnel, for instance, and the default SOAP extension doesn't work in WSDL mode over this, for instance. Although it's one lever higher up than http itself, it's still between http and services themselves
12:22 < hejrocker> not like dixon_ has anything to do in qatar since he cant get booze :P
12:23 <@Crell> lol
12:23 < skwashd> voxpelli, can't we just fall back to $_COOKIES?
12:23 <@Crell> Context values.
12:23 < voxpelli> skwashd: No - everything should go through the http-lib - right Crell?
12:23 -!- bojanz [~bojanz@drupal.org/user/86106/view] has quit [Quit: bojanz]
12:23 <@Crell> voxpelli: Ideally, any use of $_* will be considered a bug when we're done.
12:23 < skwashd> hejrocker, i wouldn't be here i couldn't get booze! :P
12:23 < hejrocker> crell even if used in order to populate the context object?
12:23 <@Crell> Moving on to item #2: Context values: Keys or full objects?
12:24 < skwashd> Crell, hang on
12:24 -!- bojanz [~bojanz@93-87-105-63.dynamic.isp.telekom.rs] has joined #drupal-wscci
12:24 -!- bojanz [~bojanz@93-87-105-63.dynamic.isp.telekom.rs] has quit [Changing host]
12:24 -!- bojanz [~bojanz@drupal.org/user/86106/view] has joined #drupal-wscci
12:24  * Crell glances at the clock.
12:24 <@Crell> skwashd: Si?
12:24 < EclipseGc> we're a little more than 1/3rd of the way through
12:24 < skwashd> $_* is handled in C before it even makes to PHP userspace
12:24 < skwashd> so there are legitimate uses for $_*
12:24 <@Crell> Yes, but in PHP it's fairly raw and insecure.
12:24 <@Crell> I fully expect the library we use to use $_* internally.  I'd be surprised if it doesn't.
12:25 < hejrocker> ok
12:25 <@Crell> But modules should never be touching those directly.
12:25 < skwashd> Crell, ok ... cool ... i get that
12:25 < voxpelli> Crell: Does the HTTP lib handle request bodies as well btw?
12:25 < EclipseGc> ok context values
12:25 <@Crell> voxpelli: That's something for the researchers to figure out, I think.
12:25 < dixon_> voxpelli: it should
12:25 < skwashd> sorry i thought we were going to be manually parsing cookies from the HTTP header
12:25 < dixon_> we'll figure out what they do
12:25 < dixon_> and how they do it
12:26 < dixon_> and why they do it
12:26 < dixon_> or why they don't :)
12:26 <@Crell> skwashd: That's why we're doing research, to figure that out. :-)
12:26 < voxpelli> That's something that would need to be very extensibkle
12:26 -!- sun [~sun@drupal.org/user/54136/view] has joined #drupal-wscci
12:26 < dixon_> voxpelli: agreed
12:26 < skwashd> Crell, ok
12:26 < voxpelli> Eg $_POST can't be used on PUT:s and we would need to support more or less any request format
12:26  * skwashd STFUs
12:26 <@Crell> voxpelli: Right.  We want a consistent handling for that.
12:26 <@Crell> Onward!
12:27 <@Crell> Context values: Keys vs. objects and service locators.
12:27 < dixon_> fight!
12:27 < EclipseGc> define service locators quicly
12:27 < sun> PUT and DELETE don't work
12:27 <@Crell> EclipseGc:  $service->nodeLoader->load($nid); // replaces node_load().
12:27 < chx> http://php.net/manual/en/features.file-upload.put-method.php
12:28 < voxpelli> sun: Services supports them - they do work and need to work
12:28 < sun> right, php://input it is.  But both have standards constraints
12:28 < catch> Crell: when you say values, are we talking about internal implementation or API or both?
12:28 <@Crell> Basically, a common factory to get to other logic objects, as distinct from context values.
12:28 <@Crell> catch: Both, I suppose.
12:28 < voxpelli> sun: We need to use something like Inpustream.module for that as well :P
12:29 < sun> PUT is supposed to put the entity as-is back to the server, which really only makes sense when putting files.
12:29 <@Crell> sun: We've moved on to the context values, please.
12:29 < sun> DELETE does not support a request body
12:30 <@Crell> The basic problem is that primitives (keys) only makes the implementation tons simpler, but objects are what most code will actually want.
12:30 -!- capnjav [~capnjav@69.166.25.173] has joined #drupal-wscci
12:30 < catch> So for me, I am really opposed to /storing/ objects in $context itself, for various reasons (which are in the issue so I won't rant).
12:30 < catch> But what you get back, usually you want the object.
12:30 -!- jcfiala [~jcfiala@8.20.208.5] has left #drupal-wscci ["Leaving..."]
12:30 <@Crell> And if we still force them to have object_load() calls everywhere, then we've only half-assed the job of dependency injection and separation of concerns so that we can do proper unit testing.
12:30 < catch> although something like language, not so much.
12:31 < EclipseGc> well...
12:31 -!- cweagans [~cweagans@unaffiliated/cweagans] has joined #drupal-wscci
12:31 < EclipseGc> if I might, page_manager has wrapper objects that do this loading (essentially)
12:31 < catch> I don't think we want $nid = $context->nid; $node = node_load($nid);
12:31 < OSInet> what is the issue# about this ?
12:31 <@Crell> catch: Agreed.
12:32 <@Crell> OSInet: http://drupal.org/node/1177246
12:32 -!- scor [~scor@drupal.org/user/52142/view] has joined #drupal-wscci
12:32 <@Crell> Key commentsa re #7, #21, and #23.
12:32 < EclipseGc> I'm wondering if we can't adapt that conceptually so that we store a very minimal object that knows what type of object it will load, and the unique key of the object, then loads lazily when it's called
12:33 < skwashd> for PUT operations ... i'd like to see entity_merge($id, $data)
12:33 -!- helior [~helior@71-83-81-130.static.rvsd.ca.charter.com] has joined #drupal-wscci
12:33 < EclipseGc> which I think is pretty much what pounard is suggesting in that issue
12:33 <@Crell> I believe so, EclipseGc.
12:33 < EclipseGc> except I don't want to have to build custom loaders for everything
12:33 < catch> EclipseGc: that's roughtly what i'm after.
12:34 <@Crell> However, that's another layer of abstraction, performance, and I don't know how easily we can do easy mocking that way.
12:34 < catch> I think we can require context providers to do that.
12:34 < EclipseGc> which brings us back to the plugins question, but I just want to acknowledge that it's there, not necessarily dive into it
12:34 < skyred> EclipseGc, so you saying object should not provide direct access to its fields/members, but the object provides "getter" methods?
12:34 <@Crell> So what would that API look like to a module developer?
12:34 < catch> it can provide direct access via ArrayAccess still if we want.
12:35 <@Crell> @EclipseGc
12:35 < EclipseGc> Crell: well, I think my main concern right now is entities
12:35 <@Crell> They're the biggest object use case, certainly.
12:35 < EclipseGc> Crell: granted a better entity system will remove this problem to some extent, but
12:36 < EclipseGc> i.e. entity_load('type', array('id));
12:36 <@Crell> Let's assume for a moment that we do get a good EntityController base class, and we can call methods on it directly rather than having 4 layers of procedural wrappers.
12:36 < EclipseGc> but I don't think that's really the point, Migrate does some of this sans ctools plugin styles
12:36 < dmitrig01> EclipseGc: that's what I suggested in #15
12:36 < EclipseGc> Crell: where we essentially have a dynamic class definition
12:37 < EclipseGc> so terms, nodes, etc can have different loader callbacks at the end of the day as long as it's registered somewhere
12:37 < EclipseGc> dmitrig01: reading
12:38 -!- fago [~fago@chello084112011033.13.11.vie.surfer.at] has quit [Ping timeout: 260 seconds]
12:39 <@Crell> dmitrig01: Give or take implementation details isn't that largely what #7 suggested?
12:39 < EclipseGc> Crell, dmitrig01: My big contention here is just that if we develop new standardized objects like entities, I don't want implementors of new "types" like that to have to implement their own context handling if a generic class will work
12:39 < EclipseGc> we did that in page_manager in D6 and it was a real pain, since we're sort of rebuilding that same infra here, I'd prefer to not revisit that dark era
12:39 <@Crell> EclipseGc: What about if they just need a thin subclass with only a scant few lines in it?
12:39 <@Crell> hm.
12:39 < EclipseGc> Crell: no one will write it
12:40 < EclipseGc> that's the problem
12:40  * Crell nods.
12:40 < dmitrig01> Crell: not really. #7 suggested returning an object with which you could choose whether to get a nid or node -- $nid = $c2['node']->value; $node = $c2['node']->node;
12:40 < EclipseGc> Crell: this is even more true with OOP, I know you love it, I love some things about it too, but it's not within the realm of casual hackers really
12:40 < catch> $entities could potentially get loaded up with $entity->id without having to load them.
12:41 < catch> so new Entity($type, $id); or whatever.
12:41 < catch> load later.
12:41 < catch> That way you can get $entity->id without loading.
12:41 <@Crell> EclipseGc: I think we have to assume that a 5 line, 1 method class is at least as approachable as hooks for new developers.  Otherwise we're assuming a level of stupidity of Drupal devs that I think is unreasonable. :-)
12:41 < catch> but the API always gives you a node object that works.
12:41 < EclipseGc> catch: if that's doable, I like it… like that entity definition gets passed to whoever is dependent on it, and when that code asks for $entity->title and it's not there, it just loads magically?
12:41  * EclipseGc doesn't even know if that's possible
12:42 < catch> EclipseGc: yeah.
12:42 -!- mallezie [53868fdf@gateway/web/freenode/ip.83.134.143.223] has joined #drupal-wscci
12:42 <@Crell> It... might be.
12:42 < catch> it's definitely possible.
12:42 < catch> I was thinking this morning about making it work with multiple load too.
12:42 < dmitrig01> Crell: $c2['node']->node->field_foo_bar, as opposed to just $c2['node']->field_foo_bar -- both loaded lazily, I just think the second is easier to use
12:42 < EclipseGc> Crell: I'm just saying that the mental investment in understanding WHY they need those 5 lines is so significant that few devs will make it that far
12:42 <@Crell> catch: So __get() would do a node_load(), and then assign all properties to $this.  Which since it's not the actual node object means edits wouldn't propagate back anyway, right?
12:42 < catch> Crell: __get() where?
12:43 <@Crell> EclipseGc: Again, with the proper docs I don't think it's any more problematic inherently than hooks.
12:43 < EclipseGc> Crell: if we can make this magic, even for a little extra overhead, I would HEAVILY suggest that we should, because this concept is hard, and most people do NOT understand it
12:43 < catch> Crell: inside the entity class?
12:43 <@Crell> catch: EntityContextThingie::__get().
12:43 < EclipseGc> Crell: ok, well I'm just putting my experience out there, I'm ok if you ignore it ;-)
12:43 < EclipseGc> Crell: and I sincerely hope you're right
12:43 < catch> Crell: hmm, I was thinking more liek this.
12:43 <@Crell> EclipseGc: A side debate I can have with you another time. ;-)
12:43 < EclipseGc> Crell: fair enough :-D
12:43 < catch> so assuming $context is ArrayAccess
12:44 < catch> $context['node'] internally ends up doing new Entity('node', $nid);
12:44 < EclipseGc> Crell: can I just stop us at this point and point out that we SEEM to have accepted #3, and said #2 will depend on the #3 implementation?
12:44 < catch> so $node is an instance of this class
12:44 < catch> with $node->nid
12:44 < catch> if you request other stuff that's not known up front, that lazy loads. We could make the properties of the entity class protected
12:45 < catch> And then do things like $node->update('title' => $title);
12:45 < catch> node->save();
12:45 < EclipseGc> catch: I'm fairly new to OOP, but I THINK I like wha you're saying :-D
12:45 <@Crell> catch: Right, so $context['node'] = new Entity('node', 5); to assign literally, and then to read $context['node']->title.
12:45 < skwashd> sorry it is almost 3am here ... i'm off to bed
12:45 < EclipseGc> catch: I KNOW I like that
12:45 < skwashd> i'll take my orders from https://docs.google.com/document/d/1-K1C8Qp6D3kjwHvPEHS3Lme0LBlIdSCLjeEL8nzAnUA
12:45 < EclipseGc> $node->save() +1000000000000
12:45 < catch> night skwashd
12:45 < dmitrig01> catch: what's the advantage of $node->update('title' => as opposed to $node->title = ?
12:45 <@Crell> catch: Wait, what?  We don't want people to be able to save from context.
12:45 < dixon_> skwashd: night, we'll catch up later
12:46 <@Crell> Thanks, skwashd!
12:46 < skwashd> bye *
12:46 < catch> Crell: so you are going to stop people using rules module?
12:46 < sun> however, that's a very common operation, Crell
12:46 < EclipseGc> Crell: if entities were real classes worth discussing, it SHOULD be possible...
12:46 < catch> Crell: writing back to context, I can live with this.
12:46 < OSInet> dmitrig01: if you set properties manually, there is no way, when you access the property to get it later, to make sure other properties have indeed been loaded or whether a load needs to be triggered
12:47 <@Crell> We don't want a plugin to be able to modify context for some other non-descendent part of the system.
12:47 < catch> Crell: however, if your function uses context, that should not prevent CRUD operations.
12:47 <@Crell> If we do that, then we can't reliably ESI cache or cache blocks independently.
12:47 < sun> ok, but what instead?
12:47 < catch> Crell: I don't think that counts if you are doing CRUD
12:47 <@Crell> catch: Explain.
12:47 < sun> $nodeToSave = $context['node']->clone() ?
12:48 < dmitrig01> OSInet: sure there is, using __get. Bear in mind __get is only called when a poperty is not found on an object. see http://drupal.org/node/1177246#comment-4716860 for an example
12:48 <@Crell> So... I'm thinking mostly on the read side, frankly.  That's where most of our time is spend.  Saving a node usually happens only in a form submission or service request or cron.
12:48 <@Crell> A block should never be writing to a node anyway.
12:48 < chx> oh the little naive Crell
12:48 < catch> Crell: there are lots and lots of sites around that are conditionally writing back to nodes or users based on some kind of event on the site.
12:49 < chx> i thought you were in the site building business? :)
12:49 < sun> mmm, did you consider the possible edge-case that my code's intention or requirement is to update the current context so that further code down in the chain picks up the right values?
12:49 <@Crell> catch: And they should be able to do that without mucking up the active user for another block. :-)
12:49 <@Crell> sun: Further DOWN the chain, yes.  That's what the mocking/layering is for.
12:49 <@Crell> Further UP the stack, if we can't assume that it doesn't happen then we cannot do reliable block caching and ESI.
12:50 < catch> Crell: well that is site specific anyway.
12:50 < OSInet> dmitrig01: sure, but then the context logic doesn't know that the object is currently dirty. anyway, we're not solving issues yet, just listing them
12:50 < catch> Crell:  we can have infrastructure for it, but we are probably not implementing that in core.
12:51 < EclipseGc> ok, let's hold on here
12:51 < sun> well, are we going to replace the stuff like hook_init()/_pager_footer()/_exit() ?  Not sure I understand how module A would be able to intentionally alter and make that available "elsewhere" in the request
12:51 < catch> Crell: so your answer to this is that you can never save anything that is also used as context?
12:52 < catch> Crell: because if you leave a 'stale' node in the context object, then you have potential race conditions all over the place as well.
12:52 <@Crell> catch: Actually my goal is to make it possible to have core auto-smart-cache blocks on its own.
12:52 < EclipseGc> if we have legitimate entity classes, then what catch suggest should be TOTALLY possible, if we want to suggest that the context system does not by default support the implications of that, it's ok, as long as it's exposed enough that a developer can get in and do his own caching implementation for these situations
12:52 < catch> Crell: right nice block caching, but not ESI.
12:52 <@Crell> Hopefully using the fancier cache clearing logic you were working on.
12:52 < catch> Crell: if you save a node, it should invalidate the block cache anyway.
12:52 -!- theunraveler [~theunrave@67-4-159-149.mpls.qwest.net] has quit [Remote host closed the connection]
12:52 -!- mallezie [53868fdf@gateway/web/freenode/ip.83.134.143.223] has quit [Ping timeout: 252 seconds]
12:52 < catch> if it is context for that.
12:53 <@Crell> catch: If we know the variables that a given block varies on via context, then block cache, in-cache ESI, and Varnish ESI are all essentially the same thing.
12:53 < catch> I hate it when I find sites that are randomly updating nodes and users fwiw.
12:53 < catch> one client site was doing node_save() 6-7 times every hook_init() one time...
12:53 < catch> Crell: I get this, but that doesn't answer my question about people who want to save nodes outside form submissions or background tasks.
12:54 < catch> If we say "don't do that", then this discussion is a non-issue
12:54 < catch> you could always queue a node for updating
12:54 < catch> or something.
12:54 < OSInet> possibly as bad, one thing i've seen more than once is a variable_set on each hook_init
12:54 <@Crell> I'd like to say "don't do that", but if we can't get away with that then we need to figure out how to do that other than just mucking with the context object directly and thereby editing the entire rest of the page.
12:54 < catch> views had one in hook_block() for a while.
12:55 < catch> Crell: I'd go for don't do that, if you want to, acquire a lock, save the node in shutdown or something.
12:55 < catch> or your caching might break.
12:55 < catch> tough
12:55 < msonnabaum> does that mean we're back to loaded entities in the context object? (sorry, missed the first bit)
12:55 < sun> doesn't the entire ArrayObject cache thingie rely on shutdown functions though?
12:56 <@Crell> Well, this is a place where using keys only would make it easier.  You can't alter the key, but you can always load the node yourself and go to town.
12:56 < sun> msonnabaum: lazy-loaded
12:56 <@Crell> (Whether that's good or bad, I don't know.)
12:56 < catch> msonnabaum: was thinking about an entity class that you have $entity->id but requesting something that's not set and it populates.
12:56 < msonnabaum> catch: that sounds nice
12:56 <@Crell> catch: Populates $this, or are you talking about an alternate interface?
12:56  * Crell still isn't entirely clear there.
12:57 <@Crell> Of course, if fields become objects, too, then that gets trickier. :-)
12:57 < catch> Crell: depends what we want to do with accessing fields.
12:57 < catch> tadaaa :)
12:57 <@Crell> heh.
12:57 < msonnabaum> what's wrong with saving that and invalidating what's cached from that object? If you're doing that you're knowingly destroying your caches anyhow
12:57 <@Crell> OK, stepping back.
12:57 <@Crell> 1) We need to allow a plugin to "edit and save a node" at an arbitrary time.  I will grant that.
12:57 <@Crell> At the same time, though:
12:58 < catch> msonnabaum: I /think/ Crell's concern if you have four blocks rendered in parallel and one of them updates the title, you could get an inconsistent page at the end of it.
12:58 <@Crell> 2) We need to not allow a plugin to muck with context in some other part of the page, only in its child function stack.
12:58 <@Crell> catch: I am more concerned about one of the block changing what node is even being displayed, but that's the basic idea.
12:59 < EclipseGc> Crell: you'd need to alter the context object itself, not the contextual node
12:59 <@Crell> I suppose "you can save the node but not change the nid" is a reasonable compromise, and at that point if you do something stupid and break your caching you file a bug against the module that's being stupid.
12:59 < catch> Crell: OK that one is definitely out.
12:59 < msonnabaum> seems like you're just mocking in that case and the other blocks are just going to be stale
12:59 < EclipseGc> Crell: I shouldn't be able to node->save() a different node into that slot in the context
12:59 < catch> if you change the nid you are creating a new node.
12:59 < sun> 2) sounds like a heavy system just for the sake of dealing with broken code to me?  Why do we assume that developers don't know PHP5?
13:00 < EclipseGc> cause developers don't know php5
13:00 < EclipseGc> ;-)
13:00 <@Crell> sun: It's not as much a question of babysitting broken code as it is architecting to allow us to make certain assumptions.
13:00 <@Crell> Because without those assumptions, we can't do other things.
13:01 <@Crell> eg, hook_page_alter means that David Strauss basically can't do reliable ESI in Pressflow 7.
13:01 < catch> block caching is broke in core right now, even the crappy one that we have :(
13:01 < catch> But hook_page_alter() is an exposed API.
13:01 < EclipseGc> Crell: sure he can, he just needs to remove all calls to drupal_alter('page') ;-)
13:01 <@Crell> But if we can assume that blocks depend on reliable known information, then block caching, ESI, and pure unit testing (with DrupalUnitTestCase) all become very simple.
13:02 <@Crell> So, stepping back a bit...
13:02 < sun> hm
13:02 <@Crell> catch: I'm still not entirely sure what your proposed EntityContext class is doing.
13:02 <@Crell> It sounds like:
13:02 < skyred> technology is also political ^^
13:02 < catch> Crell: i'm not sure either, it was only this morning.
13:02 < sun> not sure I understand why we can't assume it without ensuring a context locking system
13:02 <@Crell> hehe.
13:03 < catch> Crell: I was thinking about the actual entity class.
13:03 <@Crell> Oh.
13:03 < EclipseGc> Crell: yeah we aren't talking entity context
13:03 < catch> maybe that distinction helps.
13:03 < EclipseGc> Crell: entity context would just use the entity class for loading the entity when it came time
13:03 < catch> So $context['node'] = new Entity('node', $nid);
13:03 < catch> that is is.
13:03 <@Crell> I'm definitely in favor of an Entity class (with possibly a Node child class) for Drupal in general.  No question at all.
13:03 < catch> that is it.
13:03 -!- timplunkett is now known as timplunkettOTL
13:04 < catch> Then $context['node']->nid gets you the nid as a protected property or whatever.
13:04 < msonnabaum> but that's all the entity class, not context
13:04 < catch> $context['node']->title triggers a full load.
13:04 < sun> btw, did we consider the case where there is no nid?
13:04 < catch> right..
13:04 < catch> with this there's no inherent overhead from just asking for the ID.
13:04 <@Crell> OK, so how does that help us in terms of objects vs. keys for what the context butler object "stores" (or provides)?
13:04 < catch> And no dual object/id API.
13:05 < msonnabaum> doesn't that mean butler is still just dealing with keys?
13:05 < OSInet> any reason to keep on using *id for entity keys and having to query the entity api for the name of the key, instead of always having it be just "id" ? less overhead
13:05 <@Crell> OK, so what about when we need to serialize the context keys for a given block for caching purposes?
13:05 < dmitrig01> Crell: butler provides objects loaded with keys
13:05 < dmitrig01> Crell: mocking is easy, just provide a different object
13:05 <@Crell> OSInet: I would actually like to see ->id() become a method. :-)
13:05 < catch> Crell: so internally store the id, entity type, class name or something.
13:05 < dmitrig01> Crell: for caching, store class name, id
13:06 < catch> Crell: but $context->node returns a class instance.
13:06 <@Crell> catch: No, at that point you're still storing an object.  It's just a smarter object.
13:06 < catch> $context['node']
13:06 < catch> Crell: returning isn't the same as storing.
13:06 < EclipseGc> catch, Crell: ok so I love the sounds of this, my one big misgiving though is that it makes wscci heavily dependent (success wise) on us having a reliable entity system.. which we don't, and I don't believe there's an initiative for such  thing, and we don't have room for it in wscci so...
13:06 < catch> Crell: offsetGet() can do what it likes.
13:06 < catch> EclipseGc: it is part of CMI and we have the first patch just about ready.
13:06 <@Crell> So if I have a block that varies based on node, user, language, and a particular HTTP header... how do I turn that into a loadable string of primitives that I can stick into a URL or cache system key?
13:07 < EclipseGc> catch: oh really?
13:07 < EclipseGc> catch: color me happy
13:07 < catch> EclipseGc: not for this stuff but it will get done.
13:07 < OSInet> have to leave, sorry. hope to read the summary later
13:07  * Crell gets his crayons and starts marking up EclipseGc.
13:07 -!- OSInet [~fgm@drupal.org/user/27985/view] has left #drupal-wscci []
13:07 < tsvenson> Have to leave now. Been most informative (didn't understand everything) and am sure great things will come out of this. Thanks all.
13:07 < catch> If D8 releases without a proper entity system I will be extremely sad.
13:07 < EclipseGc> catch: you me and many other people
13:07 < catch> And I'll be even more sad if we add lots of workarounds just in case it doesn't.
13:07 <@Crell> catch: Are you going to be in London?
13:07 < EclipseGc> catch: a proper entity system is so important at this point I would hack all my D7 core sites for it
13:08 < hejrocker> half my initiative is broken to hell without it
13:08 < catch> Crell: no :(
13:08 < EclipseGc> given a useful patch
13:08 <@Crell> D'Oh!
13:08 -!- tsvenson [~tsvenson@46.24.135.136] has left #drupal-wscci []
13:08 < catch> I'm going to be in London in October.
13:08 -!- mallezie [53868fdf@gateway/web/freenode/ip.83.134.143.223] has joined #drupal-wscci
13:09 <@Crell> <Crell> So if I have a block that varies based on node, user, language, and a particular HTTP header... how do I turn that into a loadable string of primitives that I can stick into a URL or cache system key?
13:09 < dmitrig01> Crell: (Entity, node:1), (Entity, user:1), (Language, de), (http:header:x, 'foo') or something
13:09 <@Crell> dmitrig01: But we need an automated way to do so, then.
13:09 < EclipseGc> dmitrig01: no
13:10 < dmitrig01> Crell: oh. more tracking in offsetGet?
13:10 < EclipseGc> Crell: I've mentioned this before, but you're in UI territory now
13:10 < EclipseGc> we want named entities
13:10 < EclipseGc> named/typed
13:10 <@Crell> My concern is if some context values are an object and we have to call ->id() on it, and others are just a string...
13:10 < hejrocker> having context values of different types seems inevitable doesnt it?
13:10 -!- arshad [~arshad@197.224.186.164] has quit [Quit: arshad]
13:10 < EclipseGc> so node_1:1 user_1:23 language_1:de
13:11 < sun> can't we wrap strings in simple stub context objects?
13:11 < EclipseGc> you can't get away with a simple name space for ANYTHING unless you ABSOLUTELY know it will be unique at all times and you'll never need another of it
13:11 < sun> or do we expect to have 500+ contexts?
13:11 <@Crell> sun: That's a fine question. :-)
13:11 < EclipseGc> sun: more like 5
13:11 < EclipseGc> imo
13:11 < hejrocker> EclipseGc, we think 5, so in reality we need to prepare for like 20?
13:11 <@Crell> http://drupal.org/node/1178762
13:11 <@Crell> We're working on that now. :-)
13:12 <@Crell> hejrocker: Yeah, probably. :-)
13:12 <@Crell> I suppose...
13:12 -!- theunraveler [~theunrave@67-4-159-149.mpls.qwest.net] has joined #drupal-wscci
13:12 < EclipseGc> hejrocker: well, I think that's PLAUSIBLE but not typical
13:12 -!- samkottler [~Adium@ool-18e488a0.dyn.optonline.net] has quit [Ping timeout: 252 seconds]
13:12 <@Crell> IF we require that all context values be objects with a ContextValueInterface, and Entities implement that interface themselves...?
13:12 < sun> the question is also granularity, no?
13:12 < EclipseGc> hejrocker: for example, I might load a view context, and then load all the nodes it returns individually… I could totally see that use case
13:13 < sun> a block's cache may not depend on entity ID 123, but on a field in it?
13:13 <@Crell> sun: I think at that point we can just assume entity as "close enough".
13:13 < dmitrig01> Crell: "string of primitives that I can stick into a URL or cache system key?" in that case it doesn't matter whether it's ID or fully loaded
13:14 <@Crell> dmitrig01: I know, but we need a way to say serialze($context, array('stuff we care about'), and get back something that we can easily use to rebuild a mocked context object.
13:14 < EclipseGc> hejrocker: but 2-5 is probably far more likely than 20
13:14 <@Crell> (For some definition of serialize() that is not PHP's own implementation.)
13:14 -!- RobLoach [~RobLoach@drupal.org/user/61114/view] has quit [Remote host closed the connection]
13:14 < dmitrig01> Crell: why is that important?
13:14 < sun> Crell: well, in light of http://drupal.org/node/1178762, granularity leads to the question of whether we have a single $context['http'] or gazillions of $context['http:cookie'], $context['http:domain'], etc.
13:15 -!- samkottler [~Adium@75.103.3.26] has joined #drupal-wscci
13:15 <@Crell> EclipseGc: Well, I can see 6 that nearly every page will use.
13:15 < dmitrig01> Crell: theoretically sholudn't a given context + given plugin (almost) always return the same html?
13:15 < dmitrig01> er result, not necessarily html
13:15 <@Crell> sun: I think that was in a large part item 3 on the agenda today, which we've not gotten to. :-)
13:15 < EclipseGc> Crell: global user, your headers, and what else?
13:15 -!- webchick [~Adium@drupal.org/user/24967/view] has quit [Ping timeout: 276 seconds]
13:15 <@Crell> EclipseGc: HTTP method, domain, path, request type, node, user.
13:16 < EclipseGc> Crell: for node pages ok
13:16 < sun> well, there's a lot I can think of
13:16 < EclipseGc> Crell: but… remove node, you have 5, and you'll always have those 5, so… more on top of that is really what I'm trying to count
13:17 < sun> drupal_environment_initialize() probably builds 10 contexts on its own alone...?
13:17 <@Crell> So we have a baseline minimum of 5.
13:17 <@Crell> sun: I expect that function to go away in favor of its stuff being lazy initialized within the context system or appropriate handlers.
13:17 < EclipseGc> sun: what are you contemplating?
13:17 < EclipseGc> oh ok
13:17 < dmitrig01> sun: i think the idea is it's lazy loaded, so the context isn't built so much as handlers are registered and when you ask for something from the context it asks the handler
13:17 <@Crell> dmitrig01: Yes, a given context + plugin should always return the same.
13:18 <@Crell> But we also want to be able to say, from a cache layer (ours or varnish), "make a fake context object with this node, user, and language, and render this block, and the block doesn't know the difference".
13:18 < EclipseGc> also, again I want to emphasize here $context['node_1']->title not $context['node']->title
13:18 < chx> pfffft deterministic programs. where's the fun?
13:18 < dmitrig01> Crell: actually, what about a "recent nodes" view?
13:18 <@Crell> chx: You go write threaded programs. :-)
13:18 < EclipseGc> dmitrig01: what about it?
13:18 < dmitrig01> chx: lol
13:18 <@Crell> dmitrig01: A fine question!  Probably that would have to cache based on time.
13:19 < dmitrig01> EclipseGc: a given context+plugin doesn't always return the same thing in case of a recent nodes view
13:19 < EclipseGc> oh cache
13:19 < dmitrig01> Crell: ok. so, what about tracking offsetGet, then asking every handler to serialize itself
13:19 < EclipseGc> dmitrig01: there's no context in that case
13:19 <@Crell> dmitrig01: The handler isn't the value.  It is the logic to FIND the value.
13:19 -!- Pasqualle_ [~Pasqualle@chello089173133023.chello.sk] has joined #drupal-wscci
13:19 < EclipseGc> dmitrig01: unless the "date" is the context
13:19 < dmitrig01> EclipseGc: well, could be, f.e. recent nodes in an OG
13:20 < EclipseGc> dmitrig01: ok, fair enough, still… the context is the OG, not the view, and views caching is imo an entirely different animal
13:20 <@Crell> So either 1) The value must be an object with a serializing method (ContextValueInterface), which means ALL values you get back from the context object are objects, not primitives.
13:20 < EclipseGc> Crell: no? ^
13:20 < dmitrig01> Crell: oh, right. hm
13:20 <@Crell> EclipseGc: Yes.
13:20 < dmitrig01> Crell: what about having two aproaches. Either it's a primitive or an instance of a ContextValueInterface?
13:21 <@Crell> 2) We have to track which handler a value came from, and then pass it back into the handler which knows how to serialize it.
13:21 <@Crell> dmitrig01: Possibly.  My concern there is that 2 is the least likely number in the universe. :-)  I fear we'll end up with a 3rd oddball, and then 4th...
13:21 < catch> dmitrig01: there is a core issue for adding cache tag support but no code yet.
13:21 <@Crell> But if we can consolidate around "it must be a primitive or ContextValueInterface", I'm OK with trying to move forward with that approach.
13:21 < catch> dmitrig01: how much that could be integrated for free with context the answer is probably not going to include content lists.
13:22 <@Crell> And then whenever the entity system gets its act in gear, we can bake that interface into entities.
13:22 <@Crell> EclipseGc: Would that satisfy your concern about it being too hard to implement new contexts?
13:22 < dmitrig01> Crell: yep. that sounds workable
13:22 <@Crell> hejrocker: Since you're mucking with entities, does that sound reasonable on your end?
13:22 < dmitrig01> catch: yes, I wasn't thinking about doing exactly that, those two examples were separate
13:23 <@Crell> Ideally, we should build context and cache tags separately, and then leverage them together for fancypants block caching once we have new blocks.
13:24 < hejrocker> i think so, althugh catch and pwolanin are really the experts on it
13:24 < hejrocker> im just giving them a house to live in
13:24 <@Crell> Are they being considerate guests? :-)
13:24 < EclipseGc> Crell: yes and no, I'm trying to express myself properly here, entities is JUST the example… others could exist… imagine a generic wrapper around anything utilizing export in ctools (for example) we just need to be able to have generic context classes that can wrap and load multiple types of objects that depend on them… i.e. I don't want to have to write a loader for node, term, user, etc… nor (if it were possible) do I want to
13:24 < EclipseGc> write one for views, or anything else using a standardized api there… I want context to support the maintainer to write 1 class that can load anything (if possible)
13:24 < EclipseGc> anything for that given type of stuff
13:24 < catch> I can likely live with entities implementing a context interface, that seems like a very reasonable requirement.
13:25 < EclipseGc> Crell: if we fail in that regard, but still support entities as a whole, I won't complain too loudly :-D
13:25 <@Crell> EclipseGc: Well, that would be the advantage of an interface.  You could build it once into the base entity system, then all entities inherit it.
13:25 < catch> EclipseGc: the advantage of this being in core is we can say use it or suck it up.
13:25 <@Crell> I... don't know at the moment how non-data objects would work, since those are not entities.
13:25 <@Crell> Eg, views.  Those are, in the new model, config objects.
13:26 <@Crell> Or an object that has been instantiated with a config object.
13:26 -!- skyred [~skyred@180.154.138.127] has quit [Ping timeout: 246 seconds]
13:26 <@Crell> So... I suppose one could implement ContextValueInterface on the View class and call it a day?
13:26 < EclipseGc> catch: yeah I hear that, but that's why I'm being such a pain about this, because the disadvantage of it being in core is that if it doesn't work for the use cases we need, we get to wait another 2 years for it to actually solve what we intended
13:26  * Crell is thinking aloud.
13:26 < catch> if it's the latter then that could also impement... yep.
13:26 < EclipseGc> catch: so I'm just being especially cautious
13:26 < hejrocker> 2 is optimistic
13:26 <@Crell> EclipseGc: Agreed, which is why I'm glad you're being cautious. :-)
13:26 <@Crell> No sense repeating Panels' pain over again if we can avoid it.
13:26 < catch> heh.
13:27 <@Crell> hejrocker: Explain.
13:27 < EclipseGc> Crell: or entities
13:27 < hejrocker> 'another 2 years'
13:27 <@Crell> lol.
13:27 < catch> I'll be glad if code freeze doesn't last 2 years again.
13:27 < hejrocker> indeed
13:27 <@Crell> Whatever the length, I agree we want to try to avoid implementing something half-assed.
13:28 < EclipseGc> Crell: this for a context wrapper makes a lot of sense, because something like language is really just a string, but we need to know what that string is
13:28 < sun> well, not always
13:28 < EclipseGc> Crell: same for any random id that represents and entity of some type
13:28 -!- mallezie [53868fdf@gateway/web/freenode/ip.83.134.143.223] has quit [Quit: Page closed]
13:28 < EclipseGc> being able to wrap those ids and strings in meta data is useful
13:28 < EclipseGc> and fairly light
13:28 < sun> we'll see heavily improved language functionality in D8, so I expect much more functions to rely on a language object holding more info than jsut a language identifier
13:29 < EclipseGc> sun: better still
13:29 < EclipseGc> doesn't really change my argument
13:29 <@Crell> sun: Right.  I don't know what Gabor's plans are for global language tracking.
13:29 < EclipseGc> string contexts from the url are useful as well :-D
13:29 <@Crell> Hence why I want to make sure we build something that can deal with whatever he ends up throwing at it.
13:30 < EclipseGc> yeah that's probably a context we can expect to always have
13:30 < sun> yup
13:30 < EclipseGc> ok lunch
13:30 < EclipseGc> bbl
13:30  * Crell is trying to write up notes here.
13:31 -!- Bojhan [~Bojhan@s3eea7bfa.adsl.wanadoo.nl] has joined #drupal-wscci
13:31 <@Crell> catch: Does this address the problem of writing back to an entity that is passed in context?
13:31 < hejrocker> i have to take off as well
13:31  * Bojhan wonders if he missed it,
13:31 < hejrocker> but i'll catch the log for the rest
13:32 < catch> Crell: sorry I am behind.
13:32 <@Crell> Bojhan: We're still talking, but nothing here is UI-related today. :-)
13:32 -!- davereid is now known as davereid|lunch
13:32 <@Crell> catch: See the google doc.  I'm trying to summarize.
13:32 < Bojhan> Crell: oki
13:32 -!- skyred [~skyred@116.233.128.222] has joined #drupal-wscci
13:32 < catch> Crell: I don't see a link to a google doc?
13:32 <@Crell> https://docs.google.com/document/d/1-K1C8Qp6D3kjwHvPEHS3Lme0LBlIdSCLjeEL8nzAnUA/edit?hl=en_US
13:33 < joachim_> 'includes a method that will return a load key for that object.  ' << to dyou mean 'return' there?
13:34 < catch> Crell: yeah I'm not sure what that means either.
13:34 -!- hejrocker [~Greg@drupal.org/user/128537/view] has quit [Quit: Leaving]
13:34 < joachim_> maybe means it takes a key?
13:35 < joachim_> ah maybe not
13:35 -!- swentel [~swentel@drupal.org/user/107403/view] has quit [Ping timeout: 240 seconds]
13:35 < joachim_> example code is appearing :D
13:35 <@Crell> Example code added.  Does that make it clearer?
13:35 -!- davereid|lunch is now known as davereid
13:35 < joachim_> yup
13:35 < catch> Crell: Ok the example helps yes.
13:35 < joachim_> so why not also add a method to ContextValueInterface loadMe() ?
13:36 < joachim_> and the node class returns node_load($this->id())
13:36 <@Crell> joachim_: Because I've not thought that far ahead yet... :-)
13:36 < catch> yeah that needs a bit more thought.
13:36 < joachim_> that's kinda what I was saying earlier, just I hadn;t thought of the interface bit :)
13:36 <@Crell> The loading of objects should be separate from the object itself.
13:36 < joachim_> oh yeah
13:37 < joachim_> yknow, for Transport I did the same kind of thing as contextKey
13:37 < joachim_> and I ended up refactoring it even further
13:37 <@Crell> Oh?
13:37 -!- dmitrig01 [~dmitrig01@drupal.org/user/47566/view] has quit [Quit: dmitrig01]
13:37 < joachim_> so I had: public $primaryKeyName;
13:37 < joachim_> and the node class defines that as 'nid'
13:38 < catch> My general feeling is if we want tricky lazy loading we should not build that into an interface.
13:38 < joachim_> and then the base class implements the id() function only once
13:38 < catch> so you can just provide an object with an id() method, and the rest is populated.
13:38 <@Crell> catch: Not into the context value interface, certainly.
13:38 < catch> And anything else is up to you.
13:38 < joachim_> it's worth noting though that there's an issue floating around to have everything just be 'id'
13:38 <@Crell> If nodes do lazy loading internally, that's not our problem.
13:38 < catch> good good.
13:39 <@Crell> joachim_: Right.  I'd rather see that be $node_id which gets returned by id(). :-)
13:39 < joachim_> but anyway, I got it down to function public_id() { return $this->{$this->primary_key}; }
13:39 < joachim_> one size fits all
13:39 <@Crell> joachim_: IMO that's an implementation detail that we should punt on right now.
13:39 < joachim_> k
13:40 <@Crell> That may well be a good idea for the base Entity class to do, but it's not something relevant for context.
13:41 <@Crell> catch: So what does this do for the question of overriding?
13:41 < catch> Crell: so this addresses my concerns about keeping copies of stuff in context, I'm not sure it addresses yours about saving entities - but I am fine with "don't do that" as an answer.
13:41 <@Crell> Er, for context encapsulation.
13:41 < catch> Crell: for mocking the context you mean?
13:41 -!- davereid is now known as davereid|lunch
13:41 <@Crell> For not allowing mocks to escape. :-)
13:42 < catch> Crell: I made need to just go pass out in a minute.
13:42 <@Crell> :-)
13:42 <@Crell> We're not getting to item 3 today.  Anyone object to another meeting next week?
13:42 < catch> especially when I'm typing made instead of may
13:42 < msonnabaum> damn, it's late in japan!
13:43 < neclimdul> catch does that mean you're already on your way to passing out? :P
13:43 < catch> Crell: the saving/child/simultaneous request issue, are we talking about the same thing?
13:43 <@Crell> catch: I think so.
13:43 <@Crell> There's... well a subtle difference.
13:43 <@Crell> I think what we're saying is that you cannot modify the context object above you, we agree on that.
13:43 <@Crell> If you try to edit the $context['node'] object directly, though...
13:44 <@Crell> That's not changing anything that the context can control.
13:44 <@Crell> $context['node']->title = 'Some new string'.
13:44 <@Crell> And we can't really stop node_save($node);
13:44 <@Crell> (Or $node->save(), whatever.)
13:44 <@Crell> I'm just not entirely sure that "don't do that or you're stupid" is a safe answer. :-)
13:44 < kombucha> :-\
13:45 < catch> Crell: stopping $context['node']->title maybe, but yeah my main argument is that we can't stop people doing $node->save
13:45 <@Crell> catch: How could we block the former?
13:45 < catch> Crell: protected properties
13:45 <@Crell> You'd still need a method to get to them.
13:46 <@Crell> If you do $node->field('myfield)->value, or whatever...
13:46 < catch> Crell: I am partly thinking about separating access and storage a bit, but none of this is far along.
13:46 < joachim_> set an extra key $node->unsaveable
13:46 < joachim_> ;)
13:46 <@Crell> catch: Is the first problem in the doc really a problem?  Wouldn't it know if it's a primitive or not?
13:46 <@Crell> Ah.
13:47 <@Crell> If our answer is "we don't want to support that but haven't figured out how to block it yet, but we'll figure that out later", I can live with that.
13:47 < joachim_> and then have drupal_write_record choke on anything with that key
13:47 <@Crell> catch: I don't follow the second problem item.
13:47 < catch> Crell: yeah I think that's the answer. There are major, major advantages to having setting of entity properties being a method call.
13:47 <@Crell> joachim_: That function needs to DIE.
13:48 < joachim_> well, whatever replaces it then
13:48 < catch> Crell: since we can then inform hooks which properties changes etc.
13:48 <@Crell> hm.
13:48  * Crell still wants to move to CRAP instead of CRUD for entities.  Which may also change things.
13:48 <@Crell> That could help, actually.
13:48 < catch> Crell: second problem item?
13:48 < joachim_> entity_save, or the DBTNG query update doodad
13:48 <@Crell> In the google doc.  Isn't that you?
13:49 < catch> Nah I didn't type anything.
13:49 < sun> me!
13:49 <@Crell> sun: Ahso!  OK, what do you mean by those two?
13:49 < sun> sorry, just one item
13:49 < catch> Crell: you should use pirate pad.
13:49 <@Crell> Meh.
13:49 <@Crell> sun: Elaborate please then.
13:49 < sun> yeah, pirate pad is much better for stuff like this, indeed
13:50  * Crell has to go soon as well.
13:50 <@Crell> Need to eat and then go to another meeting. :-)
13:50 < sun> well, I fear the concurrent support of primitives and objects will lead to ugly code scattered throughout the system
13:50 <@Crell> sun: Well, presumably a caller will know that http:get:page is a string and user is an object.
13:52 < sun> I can get behind that to some extent, but code that reads like:  $foo = $context['http:get:page'] . $context['user']->id();   is going to look very odd.
13:52 <@Crell> sun: True.  I'm just not sure there is a better solution.  If you have one please share. :-)
13:53 < sun> adds the requirement for a giant handbook page that explains developers what's an object and what's not
13:53 <@Crell> I suppose $context['user:id'] could be something the handler does?
13:53 <@Crell> And it would internally take user and call ->id() on it?
13:53 < sun> well, I'd just simply go with every-context-value-as-object
13:53 < sun> also makes it easier to enhance contexts over time/in the future
13:54 <@Crell> That introduces potentially a lot of overhead to have to write a class for every little into or string.
13:54 < catch> couldn't we have a base class that just wraps literals?
13:54 < sun> well, httpGetPageContextValue extends SimpleContextStringValue ?
13:54 <@Crell> catch: Hm.  Maybe.
13:54 < sun> for example
13:54 <@Crell> But then EVERY context value will have to be accessed with ->id() on the end of it.
13:55 < sun> consider the language topic raised earlier -- right now we'd have a language ID string in there.   But as soon as D8MI gets on full track, we'd want to have a richer object
13:55 < sun> Crell: sure, why not?
13:55 <@Crell> DX, and then we may want to start counting stack calls.
13:56 < sun> or just make it ->id and skip a function call ;)
13:56 <@Crell> Do we really want to have to do $context['http:get:q']->id(); ?
13:56 <@Crell> Esp. in form processing.
13:56 -!- swentel [~swentel@drupal.org/user/107403/view] has joined #drupal-wscci
13:56 < sun> __toString() ?
13:57 <@Crell> Then we can't use that for anything else.  That bit us a few times in DBTNG.  Damien can tell you all about that. ;-)
13:57 < sun> actually, most form processing shouldn't have a need for http:get:q context :P
13:58 <@Crell> No, but lots of http:post context. :-)
13:58 < sun> form callback and hook_form_alter() gets a context, which contains form_state
13:58 < catch> Why is there a separate key for http though?
13:59 < catch> hmm, caching though.
13:59 < catch> but $context['http']->get('q'); how much context is really going to be string literals?
14:00  * Crell strokes his goatee.
14:00 <@Crell> You're suggesting that $context['http'] BE the Zend/Symfony http object (give or take a subclass)?
14:00 < sun> at least I assume that you don't want to rewrite Form API as part of this initiative ;)
14:00 <@Crell> sun: I haven't committed to yet, anyway. ;-)
14:01 -!- GaborHojtsy [~anonymous@54037B5F.catv.pool.telekom.hu] has quit [Quit: GaborHojtsy]
14:01 <@Crell> But if we can handle form submission without building most of the page first, that would be great.
14:01 < catch> Crell: possibly.
14:01 <@Crell> Looking at the list in the issue, I think pretty much all request context will be primitive.
14:01 <@Crell> Derived context is about half and half.
14:01 < catch> Crell: I'm just wondering why we have a delimited string that would end up being method calls that would return a string that would go into an object.
14:01 < EclipseGc> ok back
14:02 < sun> yeah, I'd also see a single HTTP context instead of many little string contexts
14:02 <@Crell> Then how would you override just one?
14:02 < EclipseGc> I know you were waiting with baited breath
14:02 <@Crell> With http:get:foo, you can easily override that key directly.
14:02 <@Crell> With http as the key, how would you override just the one key?
14:02 < sun> ->set() ?
14:02 <@Crell> That would have to be done on the http object itself, and then that's another place where overriding can happen that we need to build an interface for.
14:03 <@Crell> sun: Then you need to be able to clone THAT, too.  And I don't know what the API for that library will be yet as we've not selected one. :-)
14:03 -!- webchick [~Adium@drupal.org/user/24967/view] has joined #drupal-wscci
14:03 < EclipseGc> wb webchick
14:03 <@Crell> I'd rather leave that API as un-mucked-with as possible.
14:03 <@Crell> webchick: Hi again.
14:03 -!- theunraveler [~theunrave@67-4-159-149.mpls.qwest.net] has quit [Remote host closed the connection]
14:04 < catch> $foo = $context['http:get:page'] . $context['user']->id();  is really not that bad though.
14:04 < EclipseGc> Crell: so.. you're saying each portion of the http request should be its own context object?
14:04 < catch> Everything since then the cure is starting to sound worse than the disease.
14:04 <@Crell> catch: Yeah, I am tending to agree.
14:04 < sun> hold on
14:04 < webchick> Hi.
14:04 < webchick> Stupid internet.
14:04 < webchick> Are we still having the IRC meeting?
14:05 < sun> what's the cache identifier/cid/whatnot of a context string value?
14:05 <@Crell> webchick: Kinda. :-)  I'm trying to finish it off because I need to eat and get ready for another meeting.
14:05 < webchick> Cool. will there be a summary posted?
14:05 <@Crell> sun: The context key and the string value itself.
14:05 < sun> looks like we pretend the value to be always identical to cid?
14:05 -!- Senpai [~Senpai@drupal.org/user/65470/view] has joined #drupal-wscci
14:05 <@Crell> webchick: yes.  We have a notes file in Google Docs: https://docs.google.com/document/d/1-K1C8Qp6D3kjwHvPEHS3Lme0LBlIdSCLjeEL8nzAnUA/edit?hl=en_US
14:05 < webchick> Yay!
14:05 < neclimdul> i'd be happy to post my log as well
14:05 < sun> not sure whether that's going to be flexible enough
14:06 <@Crell> neclimdul: Sweet.  Attachment to the existing thread on g.d.o?  I'll post the written summary there as well later today.
14:06 < sun> so I'd still rather go with consistent objects all over the place :P ;)
14:06 <@Crell> sun: How so?
14:06 < neclimdul> Crell: sure
14:06 < webchick> CLA?
14:06 < EclipseGc> cla?
14:06 < EclipseGc> what is cal?
14:06 < EclipseGc> cla*
14:06 < webchick> That's what I'm asking.
14:06 < webchick> Open license.  (Zend requires a CLA, Symfony does not.  
14:06 <@Crell> Contributor License Agreement.
14:06 < EclipseGc> aaaah ok
14:06 <@Crell> You have to sign something before you can send in a patch.
14:07 < EclipseGc> I assume we as a community can't "sign something"
14:07 <@Crell> Right.  Individuals can, as can companies.
14:07 < EclipseGc> k
14:07 <@Crell> That's only an issue if we want to submit fixes back upstream.
14:07 <@Crell> Which, you know, I'd like to be able to do, being all open source citizens and all. :-)
14:07 < webchick> Then when's the next meeting so we can revisit the HTTP library decision?
14:08 <@Crell> webchick: Probably in a week.  We have two people who are going to research those two this weekend and report back.
14:08 < webchick> I saw that. Awesome. :D
14:08 <@Crell> If the cache key is::  domain:example.com|node:5|user:3, isn't that sufficient?
14:08 < sun> Crell: I'd table the question
14:08  * EclipseGc grrrs some more
14:08 <@Crell> sun: Well, ideally we want to try writing more code this week. :-)  I really want to have something we can start building on by London.
14:08 < EclipseGc> can we stop using node:5 user:3 notation?
14:08 < EclipseGc> it's unrealistic
14:09 <@Crell> EclipseGc: Eh?
14:09 < sun> um, that's almost token syntax? :-D
14:09 < EclipseGc> these items have to have names, not simply BE a node
14:09 < EclipseGc> node_1:5
14:09 <@Crell> The delimiters are irrelevant at the moment. :-)
14:09 < EclipseGc> user_1:3
14:09 <@Crell> EclipseGc: Oh.  Whichever.  That's irrelevant to the key question.
14:09 < EclipseGc> which means you're really passing node_1|user_1
14:10 <@Crell> huh?
14:10 < EclipseGc> ok, I will stifle my comments then
14:10 <@Crell> Ideally the names of keys can be independent of the implementation, aka we can punt that question to later. :-)
14:10 < EclipseGc> well, as I cache key, don't we really care about WHICH page this is?
14:11  * EclipseGc is just getting back into the conversation
14:11 <@Crell> For a given block, no.
14:11 < sun> Crell: well, I'd strongly recommend to strive for consistency.  But it appears to me that the ultimate answer relies on the question which http library to use and stuff
14:11 < msonnabaum> all that seems dependent on what happens with cache tags
14:11 < msonnabaum> Crell's example looks like cache tags delimited by |
14:11 < EclipseGc> Crell: a given block can only be cached per page instance
14:11 < EclipseGc> Crell: if it consumes context of configuration
14:11 < catch> right, tags != keys most of the time.
14:11 < EclipseGc> or*
14:12 <@Crell> catch: Right.  But we want to be able to turn keys into cache tags automagically.
14:12 < catch> Crell: nope.
14:12 -!- voxpelli [~anonymous@83.176.255.215] has quit [Quit: voxpelli]
14:12 <@Crell> OK, well *I* want to be able to turn context keys into cache tags automagically. :-)
14:12 < catch> Crell: domain.example.com should not be a tag.
14:12 <@Crell> that's a tag value.
14:12 <@Crell> er, domain is a tag, example.com is value.
14:13 < catch> Crell: why do I need to clear caches based on the domain the site is on?
14:13 <@Crell> (I'm assuming that the domain is one of the first-level http headers.)
14:13 <@Crell> On most sites I expect it to be just *, frankly.
14:13 < catch> Crell: tags should only be used for things which have events associated with them that can invalidate the cache.
14:13 <@Crell> But per http://groups.drupal.org/node/148149, domain is one of the keys we're considering using right at the beginning of the request.
14:13 < catch> Crell: the key is for granularity.
14:14 <@Crell> Right.  On a site using domain access, the domain would matter.
14:14 <@Crell> For a site that isn't, it wouldn't.
14:14 <@Crell> I was just picking out a couple of example keys there.
14:14 <@Crell> Not saying that all blocks would have to have a domain component to them.
14:14 < EclipseGc> still, I'm sort of confused by this caching question, because we can only cache the output of a block per instance
14:15 <@Crell> EclipseGc: I don't know what you mean.
14:15 < msonnabaum> well, that warrants a different cid, but that's still not that useful in a cache tag
14:15  * Crell really has to go, people! :-)
14:15 < EclipseGc> Crell: later then
14:15 < catch> Crell: what msonnabaum said - tag and cid need different data, but later for me too.
14:15 < catch> night!
14:15 < EclipseGc> bottom line, blocks consume context or configuration, they change for every context they consume
14:15 < EclipseGc> which changes per page
14:16 < EclipseGc> thus an instance of a block
14:16 <@Crell> https://docs.google.com/document/d/1-K1C8Qp6D3kjwHvPEHS3Lme0LBlIdSCLjeEL8nzAnUA/edit?hl=en_US
14:16 <@Crell> Anything else that needs to be added to the notes?
14:16 -!- ygerasimov [~ygerasimo@arrivally-pluck.volia.net] has joined #drupal-wscci
14:17  * Crell needs to finish up before Tiffany kills him for spending too much time on non-client work... :-)
14:17 <@Crell> Going once?
14:17 <@Crell> Going twice?
14:18 < EclipseGc> sold
14:18 < EclipseGc> get out of here
14:18 < EclipseGc> ;-)
14:18  * Crell bangs a gavel.
14:18 <@Crell> Meeting is adjourned!
14:18 <@Crell> Thank you everyone!  This has been extremely productive.
14:18 < Senpai> Yay!
14:18 <@Crell> I'll try and setup another meeting for next week sometime.
14:18  * Senpai was late, way late, and kinda missed the whole thing.
14:18 <@Crell> There will be notes and logs.
14:18  * Crell scrams.
14:18 < Senpai> I suspected as much. :)
14:19 <@Crell> Later, everyone!
14:19 < EclipseGc> ciao