[14:54] peller: hi tom
[14:54] ttrenka: hey.
[14:54] ttrenka: i don't know how long I'm going to stay, I'm dealing with a splitting headache
[14:54] peller: I've been away from this data discussion so long, I probably won't understand a word.
[14:55] ttrenka: I don' t know that its changed that much, to be honest
[14:55] peller: yeah, I'm probably not able to stay on too long either
[14:57] brian_skinner has joined #dojo-meeting
[15:01] slightlyoff has joined #dojo-meeting
[15:01] slightlyoff: hey all
[15:01] ttrenka: hey
[15:01] brian_skinner: hey :-)
[15:01] ttrenka: i don't know how long I'm going to stay, I'm dealing with a splitting headache that's lasted two days so far
[15:01] brian_skinner: looks like chris isn't here yet
[15:02] ttrenka: but I'll try to stick around as long as i can
[15:02] brian_skinner: bummer -- sorry to hear about the headache
[15:02] ttrenka: yeah, me too
[15:03] brian_skinner: ttrenka: thanks for the mail about the get() method -- i appreciate all the feedback you're giving -- i'm working right now on writing up some responses
[15:03] ttrenka: ok cool
[15:03] ttrenka: so am I missing something there at all?
[15:04] peller: I was trying to remember why, but tracking gets did matter in some situations
[15:04] peller: such as calculated values
[15:04] ttrenka: at the field level?
[15:04] brian_skinner: let me write one more paragraph, and then i'll send the mail
[15:04] peller: though I guess we could argue over whether that should be supported
[15:04] ttrenka: ok, sounds good
[15:04] peller: I'll leave it to Brian :)
[15:06] slightlyoff: peller: if we don't need it for the 90%, drop it
[15:06] slightlyoff: peller: also, could you connect() should you really need to know?
[15:06] peller: it's a very cool feature... Laszlo uses it extensively
[15:07] peller: but the tradeoff of complexity in the architecture and APIs may outweigh its usefulness
[15:07] brian_skinner: okay, just sent the mail
[15:08] brian_skinner: phone call -- back soon
[15:08] ttrenka: k
[15:08] slightlyoff: k
[15:08] jaxsphere has joined #dojo-meeting
[15:08] jaxsphere: hi
[15:09] ttrenka: hey
[15:09] slightlyoff: hey chirs!
[15:09] slightlyoff: geez, I can't type
[15:09] slightlyoff: this is what I get for trying to take a nap just before a meeting = )
[15:09] jaxsphere: sorry i'm late
[15:10] jaxsphere: waiting for souzis?
[15:10] ttrenka: sorry, brian's on the phone
[15:10] jaxsphere: k
[15:11] peller: slightlyoff: perhaps we should postpone for further discussion in the meeting, but I don't think you can connect to a field in a hash. That's the reason for the gets...
[15:11] peller: if only we had ECMAScript getters and setters...
[15:12] slightlyoff: peller: no, I understand, but you can connect to the get() method = )
[15:12] slightlyoff: oh, hey, speaking of getters
[15:12] ttrenka: oh, that connect. I was wondering what you were referring to
[15:12] peller: ok. it was the get itself that makes things so awkward
[15:13] slightlyoff: ttrenka: I vaguely remember some sort of "getters and setters" for JScript via VBScript?
[15:13] slightlyoff: ttrenka: am I smoking crack on that?
[15:13] ttrenka: you're smoking crack :)
[15:13] ttrenka: i'd hate to even attempt to pull something like that too
[15:14] ttrenka: it'd mean having both interpreters loaded in memory
[15:14] ttrenka: but I can go look and see if there's something out there.
[15:14] slightlyoff: I think that Safari is gonna give us Getters and Setters soon
[15:14] slightlyoff: (if it's not already there)
[15:15] slightlyoff: which makes IE the odd man out (as usual)
[15:15] ttrenka: that'd be nice, but MS breaks the model no matter what
[15:15] slightlyoff: howso?
[15:15] ttrenka: IE odd man out :)
[15:15] ttrenka: was saying the same as you
[15:15] brian_skinner: okay, I'm back -- sorry about that -- i'm dealing with a minor medical annoyance this week -- may need to go again in a few minutes if my doctor calls back
[15:16] slightlyoff: =
[15:16] brian_skinner: hi jaxsphere
[15:16] jaxsphere: so we want to go through the latest rev of the datamodel api's?
[15:16] jaxsphere: scenarios, etc.?
[15:16] brian_skinner: oops, gotta go again
[15:17] slightlyoff: ...which brings me to thanking everyone for being so patient and trying so hard to get dojo.data right = )
[15:18] brian_skinner: back again
[15:18] brian_skinner: sorry
[15:18] ttrenka: reading your email
[15:19] ttrenka: so brian, what kind of data store sizes are you anticipating?
[15:19] jaxsphere: no agenda put together for this meeting, but i think one of the goals is to do a final pass review with key stakeholders of scenarios/api's, hammer out any remaining major areas of differences, and scope to initial implementation...
[15:19] slightlyoff: dumb question, am I cc'd on that last email?
[15:20] ttrenka: it was to dojo-dev
[15:20] brian_skinner: slightlyoff: it went to the dojo-dev list
[15:20] ttrenka: so probably
[15:20] slightlyoff: thanks
[15:21] brian_skinner: jaxsphere: right -- no real agenda -- just wanted to try to get things kicked-off -- see who's interested in collaborating, figure out if we want to try to nail down an API for 0.4 -- figure out if we want to have weekly meetings like the accessibility folks do
[15:21] jaxsphere: we need to support large datasets >million records server side (but determine appropriate cache size for client paging)
[15:21] ttrenka: not sure getting to 0.4 is possible
[15:21] ttrenka: but definitely 0.5, I think
[15:21] jaxsphere: i think 0.5 more likely
[15:21] brian_skinner: okay, 0.5 then
[15:22] slightlyoff: yeah, I'm about to start driving 0.4 really hard, and that'll probably cut this out
[15:22] jaxsphere: but we should start coding as soon as 0.4 locked down
[15:22] ttrenka: ok, so from what I'm seeing in the email is that you think using get would be good for lazy loading situations
[15:23] ttrenka: that scares me a little, to be honest
[15:23] brian_skinner: lazy loading -- XML data representation -- derived attributes
[15:23] ttrenka: because it seems like that means it's tied to a server implementation
[15:23] ttrenka: let's come back to XML data rep in a bit
[15:23] brian_skinner: the API isn't tied to a server implementation
[15:24] brian_skinner: just the datastore implementation
[15:24] ttrenka: no, but creating a getter API on a field level implies that there is a specific way a server is expected to fill that, no?
[15:24] brian_skinner: e.g. a Delicious datastore implementation knows how to talk to the delicious data store
[15:25] brian_skinner: ttrenka: i don't follow the last question -- can you re-phrase
[15:25] ttrenka: sure, let me look at your email and try to figure out the best way of expressing what I'm thinking
[15:26] ttrenka: I'm looking at your paras on lazy loading with reference faulting and partial objects
[15:26] ttrenka: and I think part of the issue is how a data store is storing things internally, (at least our common understanding of how a store would store things internallyP)
[15:27] ttrenka: i'm starting to think that your expectation
[15:27] ttrenka: (correct me if I'm wrong)
[15:27] brian_skinner: or, maybe we shouldn't dive down into specific API things right now, if you may need to go soon -- might be better to spend our time talking about how much time we each have to work on this, and what the best way to collaborate
[15:27] ttrenka: is that a data store will hold data in whatever way it sees fit
[15:27] ttrenka: i'm trying to deal, it's just a headache
[15:28] ttrenka: if it feels like one of my eyeballs is going to pound out of my head, I'll stop :|
[15:28] brian_skinner: ttrenka: yes, the idea is that different datastore implementations can use different data representations
[15:28] ttrenka: ok, but then what do the providers do again then?
[15:28] brian_skinner: http://dojo.jot.com/WikiHome/DojoDataArchitecture
[15:29] brian_skinner: i'm beginning to think of a data provider as being essentially the same thing as a data store implementation
[15:29] ttrenka: i see
[15:29] ttrenka: i don't know that that's a good idea, and probably that's the main point of departure for where I'm coming from with the get() question
[15:29] brian_skinner: a data provider knows how to talk to some server, and the data provider implements the data store API
[15:30] ttrenka: i think I'm seeing the difference, hang on a sec
[15:31] ttrenka: ok, i think I see it
[15:31] brian_skinner: ?
[15:31] ttrenka: so the basic difference between what I thought we were talking about and what you're talking about with the architecture is how data is internally stored in a Store
[15:31] ttrenka: and that makes all the difference when we start discussing how to access it
[15:31] brian_skinner: okay, how were you envisioning it?
[15:32] ttrenka: ...my original impression was that we would use a provider to translate a specific data format to a common internally used one
[15:32] jaxsphere: that's one possibility
[15:32] ttrenka: for instance, you'd use an RDF provider to populate a store by translating RDF to a native JSON structure
[15:32] ttrenka: (or however the internal rep is done)
[15:33] jaxsphere: but having a single internal format that canonicalizes everything is not always the best thing to do
[15:33] ttrenka: ...suddenly a lot of what you've been talking about on the wiki is becoming clear
[15:33] brian_skinner: right -- i don't think the two approaches are mutually exclusive
[15:33] ttrenka: jaxsphere: can you think of a situation?
[15:33] jaxsphere: sure
[15:34] jaxsphere: XML native browser support, XML coming in, stored internally by provider using browsers built in DOM capabilities...no convertion necessary
[15:34] brian_skinner: we could have 20 different data store implementations -- 15 of them could use a common shared data representation, and just have different data provider thingies -- and the other 5 could use weird custom data representations
[15:34] jaxsphere: more efficent than converting to internal JS object structures and trying to keep the two in sync
[15:34] ttrenka: there's a lot of overhead in maintaining an XML representation
[15:34] ttrenka: a lot of overhead
[15:34] jaxsphere: even more with taking XML in, converting to JS, and having to reconvert going outbound
[15:35] jaxsphere: it depends on your scenario as to which is better
[15:35] ttrenka: depending on how often you are doing that, yes
[15:35] jaxsphere: I like the api currently, because it gives us the flexibility to do both...
[15:35] ttrenka: I did some quick monte carlo type tests on the SimpleStore? I'm using to back the FilteringTable...
[15:35] slightlyoff: ttrenka: I'm actually willing to buy that XML-only in some cases is gonna be a shit-ton fater
[15:35] slightlyoff: ttrenka: the TIBCO guys confirmed as much
[15:35] jaxsphere: it also allows XML converted to JS and back case...if you want it
[15:36] ttrenka: in FF/OS X, I had absolutely no problem pushing 10,000 JSON objects in less than a second
[15:36] ttrenka: complex objects, 3 levels of nesting
[15:36] brian_skinner: okay, so it may or may not be a win, but that should be a choice that we leave for person who implements the data store -- we shouldn't come up with an API that prevents some implementation choices
[15:36] ttrenka: which is to say that it's a start
[15:36] ttrenka: well
[15:36] ttrenka: all I'm saying is that it might be more beneficial to concentrate that in the provider APIs
[15:37] jaxsphere: not everyone works only with JSON thjo
[15:37] slightlyoff: yes
[15:37] ttrenka: but you are working with JS in Dojo.
[15:37] slightlyoff: so the TIBCO guys had an interesting solution
[15:37] ttrenka: slightlyoff: speak :)
[15:37] slightlyoff: they always put a facade around their XML data
[15:37] slightlyoff: a node accessor layer
[15:37] ttrenka: ok
[15:37] jaxsphere: that's what's being proposed here...the DataSource? API
[15:37] jaxsphere: is a facade
[15:37] slightlyoff: jaxsphere: yep
[15:37] slightlyoff: exactly
[15:38] slightlyoff: so something like that which can prevent internal transformation would be idea
[15:38] slightlyoff: but the JSON part could implement the same APIs
[15:38] ttrenka: and the performacne on that is what?
[15:38] jaxsphere: exactly
[15:38] ttrenka: slightlyoff: was it very good, ok, bad?
[15:38] slightlyoff: ttrenka: freaking amazing
[15:39] ttrenka: fast? all browsers?
[15:39] slightlyoff: ttrenka: much better than I would have expected
[15:39] slightlyoff: ttrenka: yes
[15:39] ttrenka: hmm
[15:39] jaxsphere: this is also what backbase is doing
[15:39] slightlyoff: but it's a natural place to plug in a very small query language
[15:39] brian_skinner: and if you are using simple JavaScript objects to store the data, then the implementation of the DataStoreAPI is trivial
[15:39] ttrenka: i'll be honest, I have nightmares about trying to use XML as an internal data representation
[15:39] slightlyoff: (OGNL, cut-down XPATH)
[15:39] brian_skinner: OGNL?
[15:40] jaxsphere: i think the key point is...you don't have to use XML if you dont want to :)
[15:40] slightlyoff: ttrenka: yeah, but we don't have a fast transform for JSON the way we do with XSL
[15:40] jaxsphere: and we should not require use of XPath
[15:40] slightlyoff: yes
[15:40] slightlyoff: jaxsphere: yes
[15:40] jaxsphere: in the data access api layer
[15:40] ttrenka: jaxsphere: no, that's not the issue for me so much
[15:40] ttrenka: jax: that's my main concern: the access layer
[15:40] ttrenka: I personally don't really care so much how something is stored, as long as it's performant
[15:41] ttrenka: ...but I do care if getting any data out of it is a PITA
[15:41] ttrenka: that's all
[15:41] jaxsphere: we've done both internally...and there are valid cases for doing either way
[15:41] ttrenka: yreah
[15:41] ttrenka: yeah
[15:41] slightlyoff: jaxsphere: is there anything gets gets us 80% of the way?
[15:41] slightlyoff: jaxsphere: something we can cut?
[15:42] slightlyoff: because I strongly suspect that the case for completeness is over-stated
[15:42] jaxsphere: sorry, 80% of the way in terms of the api complexity?
[15:42] ttrenka: in terms of what we need to really support
[15:42] ttrenka: i think
[15:42] slightlyoff: in terms of capability
[15:42] slightlyoff: yep
[15:42] brian_skinner: adam souzis had some good suggestions about pruning the API
[15:42] slightlyoff: like, is there some subset of what would be really great to have that we can ship with SRTL
[15:43] brian_skinner: SRTL?
[15:43] jaxsphere: so, there have been lots of email threads and I'm losing track of the latest proposal, but i think we're saying for first pass not to deal with paths in data access api
[15:43] brian_skinner: OGNL?
[15:43] slightlyoff: Sooner Rather Than Later
[15:43] brian_skinner: thanks
[15:43] ttrenka: jax: I'm not sure that that's the case
[15:43] slightlyoff: Object Graph Notation Language
[15:43] brian_skinner: thanks
[15:43] ttrenka: I was able to very quickly put together a very basic path access mechanism for SimpleStore?
[15:44] jaxsphere: there's always the e4x syntax
[15:44] ttrenka: that included calcuated results
[15:44] ttrenka: slightlyoff: that's a subset of XPath?
[15:44] slightlyoff: jaxsphere: would that be something you'd be happy transforming down to XPath?
[15:44] jaxsphere: . / [] notation was another proposal
[15:45] jaxsphere: i think a very simple path notation that allows access to reference object props would be good. Once we include indexing, gets more complex
[15:45] jaxsphere: issues like specifying keys, etc.
[15:45] ttrenka: (slightlyoff: also, do you know what size datasets TIBCO was working against? I'm curious)
[15:46] slightlyoff: ttrenka: think biological research
[15:46] brian_skinner: right, any one feature may be easy to implement in any one particular datastore implementation -- but by adding that feature as part of the API, we then require all datastore implementations to offer the same feature, which may not be so easy in some cases
[15:46] jaxsphere: as long as we have a way to get at a collection property with an iterator, use JS code to navigate down
[15:46] ttrenka: DNA strand tracking?
[15:46] slightlyoff: ttrenka: yes, stuff like that
[15:46] slightlyoff: ttrenka: big, big data sets
[15:47] ttrenka: slightlyoff: very interesting
[15:47] ttrenka: very different from the (wonderful) experiences I've had working with XML as a data source
[15:47] slightlyoff: so it sounds like we have some good alternatives
[15:47] * ttrenka looks to see if anyone notices the dripping sarcasm)
[15:47] jaxsphere: OT: we also need to talk about search api
[15:47] slightlyoff: ttrenka: yes, we noted = )
[15:47] jaxsphere: or lack thereof
[15:48] ttrenka: i think that's what we're discussing with the XPath talk?
[15:48] jaxsphere: can we agree that for first iteration, we'll only support '.' style property access notation for paths?
[15:48] jaxsphere: and no indexing operator for collections?
[15:49] slightlyoff: I'm for less up front = )
[15:49] slightlyoff: so yeah
[15:49] slightlyoff: that seems fine
[15:49] brian_skinner: i'm for less up front too
[15:49] ttrenka: ditto
[15:49] brian_skinner: happy to ditch the indexing operator
[15:49] jaxsphere: yeah!
[15:49] brian_skinner: what would the '.' style notation do?
[15:49] brian_skinner: does it return single items or collections?
[15:49] jaxsphere: same as JS notatoin
[15:49] slightlyoff: that was my next question = )
[15:49] ttrenka: I suppose that depends
[15:50] ttrenka: that is a good question
[15:50] jaxsphere: property access, single or multi valued
[15:50] ttrenka: are we assuming that records in a data store start with a root?
[15:50] jaxsphere: return Object or dojo.collection.Iterator
[15:50] ttrenka: ornot
[15:50] slightlyoff: oh dear god I hope so
[15:51] jaxsphere: yes
[15:51] ttrenka: I guess here's what I mean
[15:51] jaxsphere: i think you have both cases
[15:51] brian_skinner: i have some reservations about the root thing
[15:51] ttrenka: with SimpleStore?, the root is implied, and any time you access something it's the first level of children
[15:51] jaxsphere: sspecify path relative to a parent object
[15:51] brian_skinner: maybe i don't understand it
[15:51] slightlyoff: if they're not, I'll synthesize a root myself = )
[15:51] jaxsphere: the parent object can be a root
[15:51] slightlyoff: yep]
[15:51] jaxsphere: or if null, assume root of dataset
[15:51] ttrenka: the store is basically the root, imhp
[15:51] ttrenka: imho
[15:52] ttrenka: hmmm
[15:52] brian_skinner: so in a CSV file, the file is the root?
[15:52] ttrenka: i think so
[15:52] brian_skinner: or there's some implicit root object?
[15:52] ttrenka: (i'm not sure about it but it seems to make senseO)
[15:52] jaxsphere: root is a collection of records
[15:52] ttrenka: ok, we're on the same page then
[15:52] brian_skinner: and what about in the case of an RDBMS
[15:52] brian_skinner: or Delicious?
[15:52] ttrenka: table, view or query result would be the root
[15:53] jaxsphere: y
[15:53] jaxsphere: result set iterator is root
[15:53] ttrenka: but then we start talking about collections of stores, I guess
[15:53] brian_skinner: wait, lets get fixed on some terminology fist
[15:53] ttrenka: ok
[15:54] brian_skinner: i've been using "data store" to mean an entire huge object graph -- for example, the entire contents of an RDBMS
[15:54] ttrenka: (grabbing some aspirin, brb)
[15:54] slightlyoff: holy shit are the jquery folks kicking our ass on docs
[15:54] brian_skinner: you may make a query that gets a "result set", which includes only some of the data items in the entire "data store"
[15:55] jaxsphere: ok, me too it's an access point to the source of data
[15:55] slightlyoff: right, but even then, you'll have an iterable interface
[15:55] slightlyoff: which I think makes most of this moot?
[15:55] slightlyoff: I throw a query at it, I get an iterator
[15:55] jaxsphere: y
[15:55] brian_skinner: a "result set" does not stand on its own -- two "result sets" from the same data store may include the same objects -- there won't be two copies of each object
[15:56] brian_skinner: so each result set has a "root" -- it's not the data store that has a root?
[15:56] ttrenka: one of the reasons why I was thinking JSON as the only internal rep was to handle things like referenced objects
[15:56] ttrenka: but yes, I'd agree with slightlyoff here
[15:56] slightlyoff: ttrenka: lets drop that
[15:56] ttrenka: either way, you get an iterable set back
[15:56] slightlyoff: references are a special case in any system
[15:56] ttrenka: true
[15:56] slightlyoff: and frankly, all you really need to know is if you've already seen it
[15:56] slightlyoff: to prevent recursive issues
[15:57] ttrenka: right
[15:57] slightlyoff: but in neither case should we ever hit that
[15:57] slightlyoff: mostly because JSON can't support that in the serialization form = )
[15:57] jaxsphere: in the case of data islands, you can think of the objects in the page as being individual identifable result sets
[15:57] ttrenka: but I think your point was (getting back) is that it shouldn't matter if the root of something is an entire RDMS or a query
[15:57] slightlyoff: yes
[15:57] slightlyoff: and the API means we never have to care
[15:58] slightlyoff: at least, I suspect that's what it means, jaxsphere?
[15:58] jaxsphere: slightly off, yes
[15:58] slightlyoff: ok
[15:58] slightlyoff: what's next?
[15:58] jaxsphere: well, that's what i think... brian, does this jive?
[15:58] jaxsphere: re: a "result set" does not stand on its own -- two "result sets" from the same data store may include the same objects -- there won't be two copies of each object
[15:59] jaxsphere: regarding search api, does anyone have experience with the A9 open search spec? http://opensearch.a9.com/
[15:59] brian_skinner: i'm still not getting it -- so in the API stuff that I proposed, the get() method always operated in the context of an object -- some of the examples that chris added had get() calls that did not pass an item
[15:59] slightlyoff: jaxsphere: I'm actually IMing w/ the guy who helped write it
[16:00] jaxsphere: ah, so the question is, which result set do those execute against?
[16:00] slightlyoff: jaxsphere: should I try to get him here?
[16:00] jaxsphere: i think that's a prob
[16:00] brian_skinner: if you don't pass in a data item to the get() call, does it try to evaluation the path using the "root" as the context?
[16:00] jaxsphere: so: sure!
[16:00] brian_skinner: and if so, what root? -- the root of the data store, or of the query?
[16:00] ttrenka: brian: I think that's what we need to decide on today
[16:01] ttrenka: that simple thing will probably shape a lot of the rest of the API
[16:01] slightlyoff: checking w/ him
[16:01] jaxsphere: hmm, i think it would be better to be explicit and always pass in the root obj, which can be a result set
[16:01] ttrenka: i wonder though
[16:01] jaxsphere: rather than have ambiguity
[16:02] ttrenka: what if the iterator returned each item wrapped in an accessor API instead?
[16:02] jaxsphere: afk 2m
[16:02] brian_skinner: jaxsphere: +1 for always passing an explicit context
[16:03] peller has quit []
[16:03] brian_skinner: ttrenka: i'm not sure i understand that last idea -- can you say more?
[16:04] brian_skinner: "what if the iterator returned each item wrapped in an accessor API instead?"
[16:04] jaxsphere: back
[16:04] ttrenka: brian: part of this is me thinking out loud, so be patient
[16:04] brian_skinner: okay, no problem
[16:04] jaxsphere: in the XML implementation that's contributed...
[16:04] slightlyoff: ttrenka: I think that might even be implied to some extent
[16:04] ttrenka: brian: thatnks
[16:05] ttrenka: ok, so right now, the iterators in the collections namespace return a raw object with get()
[16:05] jaxsphere: each <dataprovider> tag captures the parameters of a search instance off a particular type of data provider implementaiotn
[16:05] peller has joined #dojo-meeting
[16:06] ttrenka: but what if instead, the accessor API (that you've got on the Store, iirc) was part of the iterator instead
[16:06] jaxsphere: and the results are placed into an object that can be located based on what was specified in the tag
[16:06] ttrenka: then the context would be the data object at the current position
[16:06] ttrenka: it would mean the store would need a querying/searching API that would return a collection
[16:07] * ttrenka goes hunting in the wiki for the actual api stuff
[16:07] brian_skinner: i think in any case we're going to want a querying/searching API that returns a collection
[16:07] ttrenka: agreed
[16:07] jaxsphere: y
[16:07] brian_skinner: http://dojo.jot.com/WikiHome/DataStoreAPI
[16:08] ttrenka: just found it, thanks
[16:08] slightlyoff: so Open Search seems a natural fit
[16:08] jaxsphere: something like execQuery({param1:a,})...
[16:08] jaxsphere: SO: yes
[16:08] jaxsphere: almost
[16:08] brian_skinner: part (11) has a query example like that
[16:08] brian_skinner: var iterator = store.fetchIterator({query: "all books"});
[16:08] jaxsphere: one thing that's a bit unclear in opensearch is the query param specification
[16:08] ttrenka: was just about to paste it
[16:08] brian_skinner: "all books" is a dumb example, but you can imagine query strings
[16:09] jaxsphere: opensearch descriptors work good for text search, but no good exemplar that I've seen for query params
[16:09] ttrenka: ok, so brian, at the same spot
[16:09] jaxsphere: so open search acts kind of like SMD files
[16:09] jaxsphere: maybe we need something like QMD :)
[16:09] ttrenka: instead of this:
[16:09] ttrenka: while(!iterator.atEnd()){
[16:09] ttrenka: var dataItem = iterator.get();
[16:09] ttrenka: var title = store.get(dataItem, "title");
[16:09] ttrenka: it'd be
[16:09] jaxsphere: the json serialization of opensearch descriptor
[16:10] slightlyoff: jaxsphere: I kinda got the feeling, but Dewitt says that there's been work to JSONify Open Search?
[16:10] ttrenka: var title = dataItem.get("title")
[16:10] brian_skinner: ttrenka: right that's the sort of API that I had in mind initially
[16:10] ttrenka: any reason why you changed it?
[16:10] brian_skinner: I called that an "object-oriented" API
[16:11] jaxsphere: s-off: if so, havent seen it...but would like to
[16:11] brian_skinner: more background here:
[16:11] brian_skinner: http://dojo.jot.com/dojo.data
[16:11] ttrenka: brian: right. Except in this case, dataItem might be a reference to a preset property in the iterator that doesn't create a new Object each time.
[16:11] brian_skinner: in the section half way down, called "Data model API -- object-oriented vs. centralized"
[16:11] ttrenka: (going)
[16:11] brian_skinner: ttrenka: ah, i see!
[16:12] brian_skinner: yes, that's interesting
[16:13] brian_skinner: and then what happens if you do this:
[16:13] brian_skinner: var dataItem = iterator.get();
[16:13] brian_skinner: var lukeSkywalker = dataItem;
[16:14] brian_skinner: var darth = lukeSkywalker.get("father");
[16:14] ttrenka: that would end up being a reference to whatever wrapper object we're using to provide field info on the current item
[16:14] brian_skinner: var name = darth.get("name");
[16:14] ttrenka: that wouldn't work.
[16:14] ttrenka: hmm
[16:14] ttrenka: but lukeSkywalker.get("father.name") would
[16:15] jaxsphere: the problem with the o-o style was that it works with single JS canonical implementation, but doesn't work with others, like XML
[16:15] brian_skinner: so i think that would be confusing -- if data items are sometimes act object-oriented but sometimes don't
[16:15] * ttrenka is thinking...
[16:16] slightlyoff: so there's this assumption that we want to hide people from everything but the primitive value
[16:16] ttrenka: yeah, I think that's part of our problem
[16:16] slightlyoff: but that breaks down when what you want is a DOM node or an JSON object
[16:16] ttrenka: and the source of a lot of complexity
[16:16] jaxsphere: y, its the member values that you want access to
[16:16] slightlyoff: so we need to get past that somehow
[16:17] jaxsphere: and you dont want to force a particular implementation in the way to access them in the api
[16:17] jaxsphere: what is wrong with the get(obj, "") approach?
[16:18] slightlyoff: what's the magical "" ?
[16:18] jaxsphere: prop name or path
[16:18] ttrenka: you end up with the same problem there though
[16:18] ttrenka: you still need to specify an access path
[16:18] jaxsphere: and get is associated the result set
[16:18] ttrenka: not if it's attached to the store itself?
[16:19] brian_skinner: i'm confused
[16:19] ttrenka: i think that's probably the most confusing part
[16:19] ttrenka: heh
[16:19] brian_skinner: so, for starters, isn't get associated with a store?
[16:19] jaxsphere: the resultset.get(obj,path/propname)
[16:19] brian_skinner: store.get(object, "attribute")
[16:19] ttrenka: right now the API says store.get(obj, path)
[16:19] jaxsphere: its the result data
[16:19] ttrenka: right
[16:19] jaxsphere: ah
[16:19] slightlyoff: "it's gets all the way down"
[16:19] ttrenka: that's what I was proposing above
[16:20] ttrenka: instead of store.get()
[16:20] slightlyoff: and the boy went on to become a great mathematician
[16:20] slightlyoff: ;-)
[16:20] ttrenka: it'd be resultset.get()
[16:20] ttrenka: heh
[16:20] brian_skinner: as long as you pass an object as the context, what's the difference between asking the resultset vs. the store?
[16:20] brian_skinner: store.get(object, "attribute")
[16:21] brian_skinner: resultset.get(object, "attribute")
[16:21] jaxsphere: there can be multiple result sets off the same store
[16:21] ttrenka: resultset seems more intuitive
[16:21] slightlyoff: actually, yeah, just make the last param optional
[16:21] brian_skinner: in either case you're asking for the attribute in the context of the object
[16:21] slightlyoff: and that'd be the identity get
[16:21] slightlyoff: "get self"
[16:21] ttrenka: and at that point I'd almost shift the get on store to be the query mechanism
[16:21] ttrenka: something like:
[16:21] brian_skinner: now i'm really confused
[16:21] jaxsphere: y, the get on store is execQuery
[16:22] ttrenka: var resultset = store.get({query:"books"});
[16:22] jaxsphere: or "retrieve contents"
[16:22] ttrenka: that works too
[16:23] jaxsphere: var results = store.query({bookName:"foo"});
[16:23] ttrenka: right, to me that is the same (with a different method name)
[16:23] brian_skinner: right, in one recent mail message I was asking if it would be okay to have different method names for get() vs. execQuery()
[16:23] jaxsphere: with open search, you would pass the query definition as a param
[16:23] brian_skinner: in my mind those two methods do different things
[16:23] slightlyoff: and that's fine by me
[16:23] ttrenka: but in the context of a store, a [get] makes more sense as a querying mech
[16:24] ttrenka: so with XML, you could pass an XPath statement
[16:24] ttrenka: etc. etc.
[16:24] brian_skinner: get() would never operate in the context of a store -- only in the context of an item
[16:24] ttrenka: no no
[16:24] jaxsphere: bk: i agree
[16:24] brian_skinner: store.get(luke, "father")
[16:24] ttrenka: brian: that's the problem
[16:24] jaxsphere: it's part of the data access api
[16:25] brian_skinner: ttrenka: what's the problem?
[16:25] jaxsphere: get on both is confusing
[16:25] ttrenka: what you're saying in that statement is "query the records in the store, find me this context, and return the attribute "father"
[16:25] jaxsphere: query a datastore and get data from result set
[16:25] ttrenka: I don't have a problem with calling it query
[16:25] ttrenka: but I don't see any reason to be getting individual data items from the store
[16:26] ttrenka: it should be through a resultset
[16:26] brian_skinner: ttrenka: what you're saying in that statement is "query the records in the store, find me this context, and return the attribute "father" -- no, that's not how i've been thinking about it
[16:26] jaxsphere: the way you specify query should be opaque
[16:26] ttrenka: ok, back up
[16:26] jaxsphere: could siply be a url, or an dataisland anchor
[16:26] brian_skinner: before you can do this:
[16:26] ttrenka: let's get away for a second.
[16:26] brian_skinner: store.get(luke, "father")
[16:26] brian_skinner: okay
[16:26] ttrenka: with store, you do this and only this: store.query(...);
[16:26] ttrenka: (no get)
[16:27] ttrenka: that returns a resultset
[16:27] jaxsphere: trenka:
[16:27] jaxsphere: but I don't see any reason to be getting individual data items from the store
[16:27] ttrenka: that resultset might have only one item
[16:27] jaxsphere: it should be through a resultset <== I agree
[16:27] ttrenka: jax: right
[16:27] ttrenka: then you access items through the resultset
[16:27] ttrenka: I think part of the problem is the term "get"; let's just not use that on a store at all
[16:27] ttrenka: sound ok?
[16:28] brian_skinner: once you have a handle to an item, like luke, it shouldn't matter what result set you got it from
[16:28] jaxsphere: things like paging offset and itemsPerPage should be part of the result set obj
[16:28] brian_skinner: luke is luke, in any result set
[16:28] ttrenka: jax: agreed
[16:28] jaxsphere: as well as optional q params
[16:29] ttrenka: brian: also agreed, I think we're trying to nail down where that item comes from
[16:29] brian_skinner: so why ask the result set for luke's father?
[16:29] jaxsphere: yes
[16:30] brian_skinner: shouldn't you just ask luke -- ideally we'd like to do luke.get("father"), but since we can't do that, this is the closest thing: store.get(luke, "father")
[16:30] jaxsphere: bk, yes, you can
[16:30] ttrenka: store.query(name="luke")
[16:30] jaxsphere: right
[16:31] jaxsphere: store.query(findByName,{firstName:"luke"});
[16:31] ttrenka: or if it's an XML store:
[16:31] ttrenka: var resultset = store.query({query:"//people[@name='Luke']
[16:31] ttrenka: well, });
[16:32] brian_skinner: okay
[16:32] slightlyoff: actually, I'm totally cool w/ letting the XML data stores convert that to XPath themselves
[16:32] ttrenka: either way :)
[16:32] slightlyoff: Open Search -> XPath ;-)
[16:32] ttrenka: (referring to the XPath)
[16:32] ttrenka: hell, we could even:
[16:32] ttrenka: var r = store.query({xpath:"//node()[@name='Luke']"});
[16:33] ttrenka: that'd be up to the store, right?
[16:33] ttrenka: what kind of query mechanisms there are?
[16:33] ttrenka: ...I'd also suggest that passing that nothing returns all records
[16:33] slightlyoff: brb
[16:33] ttrenka: var everything = store.query();
[16:34] brian_skinner: are we talking about client-side queries, or queries that get sent to the server, or are we talking about trying to hide that distinction?
[16:34] ttrenka: client side
[16:34] ttrenka: I think all we've discussed so far is client side
[16:35] ttrenka: (or am I wrong about that?)
[16:35] brian_skinner: okay, seems like it would be good if we could come up with two different words for the client-side queries and server-side queries
[16:35] ttrenka: ok
[16:35] ttrenka: retrieve/persist for server side?
[16:35] jaxsphere: afk 2m
[16:36] brian_skinner: i was thinking of "query" for the server-side one -- since query is the common term in the database world
[16:36] brian_skinner: but then I don't have a good suggestion for the client-side one :-)
[16:36] ttrenka: heh
[16:36] ttrenka: understood
[16:36] ttrenka: i'm not too keen on query for the client myself.
[16:36] ttrenka: (that's why I was using "get")
[16:38] jaxsphere: back
[16:38] brian_skinner: thinking out loud... filter? find? subset?
[16:38] ttrenka: hmmm
[16:38] brian_skinner: search?
[16:38] jaxsphere: find
[16:38] jaxsphere: search
[16:39] ttrenka: fetch>
[16:39] ttrenka: ?
[16:39] jaxsphere: fetch sounds like an iterator operation
[16:39] ttrenka: true
[16:39] brian_skinner: find?
[16:39] ttrenka: find works for me
[16:40] jaxsphere: ok, its shorter than search
[16:40] ttrenka: although store.find() isn't very clear
[16:40] jaxsphere: store.search(terms)
[16:40] ttrenka: (without a param, I mean)
[16:40] jaxsphere: that is more readable
[16:40] brian_skinner: what about store.findAll(), rather than store.find()
[16:41] ttrenka: hmm...think i'd rather let it be no param :)
[16:41] brian_skinner: okay
[16:41] brian_skinner: although, even store.query() would be confusing with no parameter
[16:41] ttrenka: true
[16:41] ttrenka: good poitn
[16:41] ttrenka: point.
[16:41] brian_skinner: not clear if it should return the empty set or the entire set
[16:42] brian_skinner: adam souzis once prosposed using an character -- like store.find('');
[16:42] brian_skinner: me, I think findAll() is the most self-documenting
[16:44] brian_skinner: ...
[16:44] ttrenka: not sure
[16:44] brian_skinner: my IRC log got truncated -- is this session getting logged somewhere?
[16:44] slightlyoff: back
[16:44] slightlyoff: sorry
[16:45] ttrenka: I think Bryan always has a logger running
[16:45] brian_skinner: URL?
[16:45] jaxsphere: ?
[16:46] jaxsphere: find(url)?
[16:46] jaxsphere: sure
[16:46] ttrenka: asking him if he's logging right now
[16:46] jaxsphere: hehe
[16:46] brian_skinner: sorry, I meant, "is there a URL where logged sessions are available?"
[16:46] brian_skinner: thanks ttrenka :-)
[16:47] jaxsphere: ot: any of you going to the ajax experience in oct?
[16:47] jaxsphere: boston
[16:47] brian_skinner: jaxsphere: not me
[16:47] jaxsphere: that's up in peller's neck of the woods
[16:47] brian_skinner: I see that DojoLog? is in the room -- is there a way to ask DojoLog? for a log file?
[16:48] ttrenka: that's bryan's logger
[16:48] slightlyoff: yeah, I'm going
[16:48] ttrenka: he hasn't responded to me yet
[16:48] slightlyoff: DojoLog?: what are you?
[16:48] * slightlyoff kicks DojoLog?
[16:48] slightlyoff: DojoLog?: help
[16:48] slightlyoff: no love = (
[16:49] slightlyoff: DojoLog? is like Dojo: it looks like it'll do what you need, but got knows how you'll figure out if it does ;-)
[16:49] brian_skinner: ;-)
[16:49] peller: heh. been trying to follow along, but it's getting chaotic here. gotta go
[16:49] peller has left #dojo-meeting []
[16:50] brian_skinner: should we think about wrapping up for today -- we've been here a couple hours, and it's getting late for the east coast people
[16:50] ttrenka: yeah
[16:50] jaxsphere: sounds good
[16:50] brian_skinner: should we make a quick plan about next steps?
[16:50] jaxsphere: y
[16:50] brian_skinner: would weekly meetings be good, or is that too much too soon?
[16:50] ttrenka: same time next week
[16:51] jaxsphere: weekly good
[16:51] brian_skinner: same time next week works for me
[16:51] jaxsphere: same time fine with me
[16:51] brian_skinner: i may have jury duty next week -- i'll let you know if that happens
[16:51] slightlyoff: well, I think all that's left to do is to prototype what's been discussed
[16:51] slightlyoff: what's not locked down are the specific returns and the APIs
[16:52] brian_skinner: slightlyoff: i think that would be dangerous -- i think it would be better to first agree on an API -- write up a summary that we all feel good about
[16:52] slightlyoff: hrm, OK
[16:52] slightlyoff: well, do we want a dojo.data mailing list?
[16:52] jaxsphere: lets fix the api specs and docs on the wiki, then implement
[16:52] brian_skinner: we're already long on prototypes, each of which has some cool features but is missing others
[16:53] brian_skinner: jaxsphere: +1
[16:53] jaxsphere: seems that we're really close
[16:53] brian_skinner: yup, we're close now
[16:53] slightlyoff: agreed
[16:53] slightlyoff: cool
[16:53] jaxsphere: maybe set goal to try to close all major api issues by next Tues, so that we can begin impl?
[16:54] slightlyoff: I'm for that
[16:54] jaxsphere: discuss issues via contrib list?
[16:54] ttrenka: ok
[16:54] brian_skinner: slightlyoff: a dojo.data mailing list would be fine -- or we can keep working on the dojo-dev list, if that's not going to create too much noise for everyone who doesn't care about the data model
[16:55] brian_skinner: jaxsphere: that goal sounds good to me -- unless i get selected tomorrow to be on the jury, in which case i'll have no time between now and next tuesday
[16:56] slightlyoff: well, if we think it's only gonna be another week until we have agreed-to APIs, lets do it on dojo-contributors
[16:56] slightlyoff: cool
[16:56] slightlyoff: so we're wrapped?
[16:56] jaxsphere: its a wrap
[16:56] brian_skinner: sounds good
[16:56] brian_skinner: thanks everybody
[16:56] ttrenka: talk to you later
[16:56] jaxsphere: slightlyoff: private channel?
[16:56] slightlyoff: awesome
[16:56] brian_skinner: we'll continue on the mailing list
[16:56] ttrenka: sounds good