Agenda

• try to resolve some of the open issues
  • package organization
    • dojo.data.api.XXX vs. dojo.data.XXX
  • naming
    • xxx.ResultSet vs. xxx.ResultList vs. xxx.Result vs. xxx.Results
    • xxx.ReadStore and xxx.WriteStore vs. xxx.ReadAccess and xxx.WriteAccess
    • commit/rollback vs. save/revert (or save/discard, save/revertToSaved)
    • byId() getIdOf() vs. byKey() getKeyOf()
    • getIterator() fetchIterator() fetchResult() fetchResult() fetch()
  • what belongs where
    • drop the fetchArry() method completely?
    • drop dojo.data.api.AsyncReadStore completely?
    • move commit()/rollback() out of api.WriteStore?
    • drop hasAttributeValue()?
    • drop getJsonString()?
  • method args and return values
    • commit()/save() -- onComplete callback? -- return a Deferred or a boolean?
    • forEach() args
      • onCompletion?
      • first/last, first/numItems, start/end?
      • forEach(someCallbackFunction)
      • forEach(someControllerObject, "someCallbackMethod")
  • other issues to work on?

• sign off on some APIs (or is it too early for this?)
  • ReadStore and ResultList
  • WriteStore

Transcript

[1:01 PM] brian_skinner: i had a go at coming up with an agenda -- http://dojo.jot.com/2006-09-12
[1:01 PM] brian_skinner: feel free to add stuff, or re-arrange the order
[1:02 PM] ttrenka: looks good to me.
[1:02 PM] jaxsphere: yep
[1:03 PM] ttrenka: i'm kind of inundated, can I just give you my responses right here, right now?
[1:03 PM] ttrenka: :)
[1:03 PM] -->| aszs (n=chatzill@h-74-0-32-234.snfccasy.covad.net) has joined #dojo-meeting
[1:03 PM] jaxsphere: hi adam
[1:03 PM] aszs: hi
[1:03 PM] ttrenka: hi
[1:03 PM] brian_skinner: ttrenka: yup
[1:04 PM] ttrenka: ok cool, here goes:
[1:04 PM] brian_skinner: hey aszs 
[1:04 PM] ttrenka: 1. dojo.data.XX
[1:04 PM] jaxsphere: aszs: agenda -- http://dojo.jot.com/2006-09-12
[1:04 PM] ttrenka: 2. Results (I'm realizing that ResultSet may make you think its a subclass of dojo.collections.Set)
[1:04 PM] -->| [algo] (n=ilia@algo.dialup.corbina.ru) has joined #dojo-meeting
[1:04 PM] brian_skinner: aszs: ttrenka has to go soon -- first he's giving us a quick rundown of his responses 
[1:04 PM] ttrenka: heh
[1:04 PM] jaxsphere: agenda -- http://dojo.jot.com/2006-09-12
[1:04 PM] [algo]: g'night
[1:04 PM] aszs: ok
[1:05 PM] [algo]: am I late or am I late ?
[1:05 PM] ttrenka: think I'd go with ...Access, but I don't care that much about it
[1:05 PM] ttrenka: you're not late
[1:05 PM] [algo]: ok
[1:05 PM] * [algo] sits down and prepares for a barbeque
[1:05 PM] ttrenka: I'm trying to get a very big, full featured charting engine in under the deadline, so I'm just shooting things out
[1:05 PM] ttrenka: I'd prefer save / revert, but don't feel strongly about it
[1:06 PM] ttrenka: ...also prefer the term "key"
[1:06 PM] ttrenka: and just fetch.
[1:06 PM] ttrenka: ...3.
[1:06 PM] ttrenka: drop fetchArray
[1:06 PM] ttrenka: remove async, and make all of it async naturally
[1:06 PM] ttrenka: no opinion on the next two
[1:07 PM] ttrenka: keep getJsonString, probably just call it getJson
[1:07 PM] jaxsphere: how about move getJson to util function on dojo.data package?
[1:07 PM] ttrenka: I think I'd want to have an onSave()/onRollback() method, and let people connect to them via event.connect.
[1:07 PM] ttrenka: sound ok to me
[1:08 PM] ttrenka: although it might be better to implement it on any read store.
[1:08 PM] [algo]: any ideas on tree widget event refactoring question I asked in contrib ?
[1:08 PM] [algo]: sorry its very late for me so I'm not for long
[1:08 PM] aszs: algo: what tz r u in?
[1:08 PM] ttrenka: [algo]: this is a dojo.data meeting, not sure anyone knows what you mean
[1:09 PM] ttrenka: ...re: forEach
[1:09 PM] [algo]: I guess, the meeting is not that close ?
[1:09 PM] ttrenka: the regular Dojo meeting?
[1:09 PM] ttrenka: it's tomorrow
[1:09 PM] [algo]: ah
[1:09 PM] [algo]: ok
[1:09 PM] ttrenka: but
[1:09 PM] ttrenka: in general, if you can set one handler as opposed to many, it's probably a good thing (definitely from a perf standpoint)
[1:10 PM] aszs: ttrenka: i still think you need the Deferred API for the Result object
[1:10 PM] ttrenka: so if you want to set those handlers on the root node, I'd say go for it.
[1:10 PM] [algo]: I can't think of a problem I can get
[1:10 PM] ttrenka: aszs: why?
[1:10 PM] [algo]: yes
[1:10 PM] [algo]: I'll refactor things
[1:10 PM] [algo]: thanks
[1:10 PM] aszs: forEach is a simplified version of brian's incrememtal callback
[1:10 PM] ttrenka: np :)
[1:10 PM] aszs: method
[1:10 PM] ttrenka: aszs: right, and?
[1:10 PM] aszs: but...
[1:11 PM] aszs: being able to cancel, pause, get a notification when the query has completed
[1:11 PM] * [algo] sleep, see you in lists
[1:11 PM] |<-- [algo] has left freenode (Remote closed the connection)
[1:11 PM] aszs: those are all important use cases
[1:11 PM] aszs: it allows for scrolling tables etc.
[1:11 PM] ttrenka: they could be handled by forEach as well
[1:11 PM] aszs: how?
[1:12 PM] ttrenka: because forEach can be an async handler, you can simply tie a closure to it, and let each execution of the function read outside values for it's thign
[1:12 PM] ttrenka: thing
[1:12 PM] aszs: i'm thinking Result inherits Deferred's interface and adds forEach
[1:12 PM] aszs: so... how to cancel the query?
[1:12 PM] aszs: how do you know when its completed?
[1:12 PM] ttrenka: we can implement that in the forEach syntax.
[1:13 PM] aszs: ok...
[1:13 PM] ttrenka: Brian had some ideas regarding that in the wiki that I thought were pretty good
[1:13 PM] aszs: the controllerobject?
[1:13 PM] aszs: parameter?
[1:13 PM] aszs: in forEach?
[1:13 PM] jaxsphere: http://dojo.jot.com/dojo.data.api
[1:13 PM] ttrenka: the object passed as an optional param, in forEach, yes
[1:13 PM] brian_skinner: you mean this?  -- results.forEach(callbackFunction, {onCompletion: finishedFunction});
[1:14 PM] jaxsphere: 		//   var results = store.fetch({query: "recent books"});            // synchronous
[1:14 PM] ttrenka: right.
[1:14 PM] jaxsphere: 		//   var results = store.fetch({query: "all books", async: true}); // asynchronous
[1:14 PM] jaxsphere: 		//   results.forEach(someCallbackFunction);
[1:14 PM] jaxsphere: 		//   results.forEach(someControllerObject, "someCallbackMethod");
[1:14 PM] jaxsphere: 		//   results.forEach(callbackFunction, {onCompletion: finishedFunction});
[1:14 PM] jaxsphere: 		//   results.forEach(callbackFunction, {first: 201, last: 300}); // partial loop
[1:14 PM] ttrenka: yes.
[1:14 PM] jaxsphere: //CCM: Allow start offset + numItems...
[1:14 PM] jaxsphere: //		     results.forEach(callbackFunction, {first: 200, numItems: 50}); // partial loop from 200 to 250
[1:14 PM] jaxsphere: //CCM: How to specify datastore-specific options to allow caching n items before/after current window of items being viewed?
[1:14 PM] jaxsphere: 		//   someCallbackFunction = function(item, resultList) {};
[1:14 PM] brian_skinner: cool, thanks jaxsphere 
[1:14 PM] ttrenka: aside from the controller param (which I'm not sure I understand), I think all of those adjustments pretty much cover it.
[1:14 PM] aszs: since it just duplicates Deferred capabilities, while not reuse that interface?
[1:14 PM] aszs: makes implementation easier too
[1:15 PM] aszs: Deferred + forEach was my thinking
[1:15 PM] ttrenka: if forEach handles everything, why bother with the deferred overhead?
[1:15 PM] brian_skinner: ttrenka: controller param is just like how dojo.event.connect can take either 3 args or 4 args -- either a callback function or a callback obj/method pair
[1:15 PM] ttrenka: brian: sounds good
[1:16 PM] aszs: i'
[1:17 PM] brian_skinner: aszs: i'm not sure i understand -- would you then be able to do this:
[1:17 PM] brian_skinner: var results = store.fetch({query: "recent books"}); 
[1:17 PM] brian_skinner: results.addCallback(foo)
[1:17 PM] brian_skinner: ?
[1:17 PM] aszs: what's the API for the controller param?
[1:17 PM] brian_skinner: dojo.event.connect allows two types of use
[1:18 PM] brian_skinner: one: dojo.event.connect(handlerNode, "onclick", "handleOnClick");
[1:18 PM] brian_skinner: two: dojo.event.connect(handlerNode, "onclick", object, "handler");
[1:18 PM] brian_skinner: one: is good for functional programming
[1:18 PM] -->| agalliar (n=chatzill@p54B2E4D0.dip.t-dialin.net) has joined #dojo-meeting
[1:18 PM] brian_skinner: two: is good for object-oriented programming
[1:18 PM] aszs: ok
[1:18 PM] aszs: yes
[1:19 PM] brian_skinner: i was thinking we'd want the same thing for the forEach() callback
[1:19 PM] agalliar: hello
[1:19 PM] aszs: how do you get a notification when the query has completed?
[1:19 PM] jaxsphere: hi, we're discussing dojo.data
[1:20 PM] agalliar: ok don't want to interrupt ya
[1:20 PM] agalliar: let me know once there is space for some general questions
[1:20 PM] jaxsphere: results.forEach(null, {onCompletion: finishedFunction});
[1:20 PM] jaxsphere: ?
[1:20 PM] ttrenka: agalliar: probably you want the #dojo room
[1:21 PM] ttrenka: actually
[1:21 PM] ttrenka: jax brings up an interesting point.  can we just make the callback a part of the param object as well?
[1:21 PM] agalliar: looks like it is down
[1:21 PM] agalliar: or empty
[1:21 PM] ttrenka: really?
[1:21 PM] jaxsphere: results.forEach(callbackFunction, {onResultsAvailable: remoteQueryfinishedFunction}); ??
[1:22 PM] jaxsphere: it's up, many users there
[1:22 PM] brian_skinner: agalliar: i just joined #dojo and it is full of people
[1:22 PM] agalliar: sorry my mistake
[1:22 PM] ttrenka: no worries :)
[1:22 PM] agalliar: thanks and bye
[1:23 PM] jaxsphere: results.forEach(callbackFunction, {onResultsAvailable: remoteQueryfinishedFunction}); ?? <-- doesnt make sense
[1:23 PM] ttrenka: anyways: results.forEach({ onComplete: fn, onEach: fn2 })
[1:23 PM] ttrenka: ?
[1:23 PM] aszs: so... is pause()/resume() a requirement?
[1:24 PM] ttrenka: i.e. let it be a single arg, like dojo.io.bind
[1:24 PM] brian_skinner: ttrenka: that would make the argument parsing easier
[1:24 PM] ttrenka: yeah, I'd think
[1:24 PM] brian_skinner: although it makes the syntax a little less pretty for the simplest use case
[1:24 PM] ttrenka: ...and to me, anything to help this feel "dojoish" would be a big plus :)
[1:24 PM] ttrenka: true
[1:25 PM] ttrenka: aszs: do you think we need a pause and resume?  it's an iteration thing, not really a timing one
[1:25 PM] aszs: i can see pause/resume() useful for scrolling a large list, but i'm not sure how important it is
[1:25 PM] ttrenka: I suppose we can implement it
[1:25 PM] ttrenka: but then we're looking at...
[1:25 PM] ttrenka: hmmm....
[1:25 PM] aszs: what about error handling?
[1:25 PM] * ttrenka has wheels spinning.
[1:26 PM] aszs: don't we need a error callback?
[1:26 PM] brian_skinner: aszs: for scrolling a large list, wouldn't {first: 201, last: 300} be more convenient?
[1:26 PM] ttrenka: that'd be a param
[1:26 PM] -->| JeffreyH (n=chatzill@user-0cevaem.cable.mindspring.com) has joined #dojo-meeting
[1:26 PM] brian_skinner: aszs: I think an error callback would be good
[1:26 PM] ttrenka: forEach({first:201, last:300, onError: errorFn})
[1:26 PM] brian_skinner: hey JeffreyH 
[1:26 PM] aszs: see, now where's duplicating deferred's interface
[1:27 PM] JeffreyH: hi folks
[1:27 PM] ttrenka: the really nice thing about the single keyword object is that we can add these things as we go without really changing the interface at all
[1:27 PM] aszs: i think forEach just take on callback function
[1:27 PM] ttrenka: at that point if we're duping deferred, that's ok
[1:27 PM] brian_skinner: quick introductions...
[1:27 PM] ttrenka: the idea here is that there's one interface for iteration
[1:28 PM] ttrenka: and that forEach hides the sync/async operation.
[1:28 PM] aszs: and cancel, completion callback, err callback, etc. look just like the deferred interface
[1:28 PM] brian_skinner: JeffreyH is Jeffrey Harris -- he's an engineer at OSAF -- the Open Source Applications Foundation
[1:28 PM] aszs: hi
[1:28 PM] ttrenka: Hi JeffreyH
[1:28 PM] brian_skinner: OSAF is interested in the dojo.data work
[1:28 PM] brian_skinner: they might make a data-store implementation that talks to their Chandler repository
[1:28 PM] ttrenka: sounds good
[1:28 PM] JeffreyH: We may be officially interested, but we have a 20% work-on-what-interests-you, so I'm considering helping out with dojo.data
[1:29 PM] brian_skinner: or they might use the dojo.data stuff in their AJAX calendar client
[1:29 PM] ttrenka: cool
[1:30 PM] brian_skinner: JeffreyH works with Ted Leung of Apache/OSAF -- Ted may get involved in a few weeks too
[1:30 PM] ttrenka: interesting
[1:31 PM] aszs: it seems to me more consistent to have Result interface = Deferred + forEach(callback) rather than forEach adding all these optional callbacks
[1:31 PM] brian_skinner: ttrenka: to cancel a forEach() loop, don't you need a separate cancel method -- can't handle that as an arg in the keyword object, right?
[1:31 PM] ttrenka: probably, uyes
[1:31 PM] ttrenka: yes
[1:32 PM] =-= agalliar is now known as rtg
[1:32 PM] jaxsphere: callback func return false == cancelled?
[1:32 PM] ttrenka: we could do it that way too, although that's a little harder to implement
[1:33 PM] ttrenka: (in some ways)
[1:33 PM] =-= rtg is now known as agalliar
[1:33 PM] brian_skinner: aszs: i'm still confused about this:
[1:33 PM] brian_skinner: var results = store.fetch({query: "recent books"}); 
[1:33 PM] brian_skinner: results.addCallback(foo);
[1:33 PM] ttrenka: (btw, where is Alex?)
[1:33 PM] aszs: only if you need a completion callback
[1:33 PM] brian_skinner: what does that deferred-style addCallback do?
[1:34 PM] brian_skinner: so, it only gets called after all the results are in?
[1:34 PM] aszs: its called when everything done
[1:34 PM] brian_skinner: okay
[1:34 PM] aszs: equivalent the completion callback
[1:34 PM] aszs: deferred = donecallback, errcallback, cancel(), pause() resume(), state attribute
[1:35 PM] aszs: if we just add a forEach
[1:35 PM] ttrenka: so is there any reason to not just implement that on forEach?
[1:35 PM] brian_skinner: i didn't realize that deferred already had a cancel()
[1:35 PM] -->| slightlyoff (n=alex@204.14.154.204) has joined #dojo-meeting
[1:35 PM] =-= Mode #dojo-meeting +o slightlyoff  by ChanServ
[1:35 PM] brian_skinner: hey slightlyoff 
[1:35 PM] jaxsphere: hi
[1:36 PM] aszs: only to minimize apis, how many api u need to learn to use dojo
[1:36 PM] aszs: hi
[1:36 PM] |<-- agalliar has left freenode ("Chatzilla 0.9.75 [Firefox 1.5.0.6/2006072814]")
[1:36 PM] brian_skinner: slightlyoff: agenda is at: http://dojo.jot.com/2006-09-12
[1:36 PM] ttrenka: I'll get Bryan to post the log for us later on
[1:36 PM] slightlyoff: thanks
[1:37 PM] brian_skinner: ttrenka: thanks
[1:37 PM] ttrenka: =)
[1:37 PM] jaxsphere: aszs, so you're suggesting Result inherits from deffered, and just adds forEach iteration, so you get the additional ops for free
[1:38 PM] aszs: yes
[1:38 PM] jaxsphere: that makes for each simpler as well
[1:38 PM] aszs: yes
[1:38 PM] aszs: just one callback
[1:38 PM] jaxsphere: and makes interface very clear as to which ops are supported
[1:38 PM] aszs: yes
[1:38 PM] ttrenka: seems to me that kind of makes it a PITA, particularly if we implement the keyword object as a single param to forEach
[1:38 PM] ttrenka: but I don't feel that strong about it.
[1:39 PM] brian_skinner: we would still want a getLength() method on Result, yes?
[1:39 PM] aszs: yes
[1:39 PM] jaxsphere: y
[1:39 PM] ttrenka: slightlyoff:  to reiterate, we've been discussing passing result.forEach a keyword-based argument object, similar to dojo.io.bind
[1:39 PM] aszs: forgot that one
[1:40 PM] ttrenka: whoa, wait a sec.
[1:40 PM] ttrenka: you aren't suggesting result.cancel(), are you?
[1:40 PM] jaxsphere:  // var results = store.fetch({query: "recent books"});  << I thought we had changed this two meetings ago to store.search({query parms});... but i missed last week.  Did we change this back?
[1:40 PM] aszs: ttrenka: why does forEach need a keyword object if it just needs one callback
[1:40 PM] aszs: ttrenka: yes
[1:40 PM] ttrenka: that puts us right back to result == iterator
[1:40 PM] ttrenka: I thought we were past that?
[1:41 PM] ttrenka: I can see result.forEach.cancel()
[1:41 PM] aszs: ttrenka: i don't understand...
[1:41 PM] ttrenka: aszs: result.forEach({ start:100, end:200, onEach:fn, onError:errorFn, onCancel: fnCancel })
[1:41 PM] ttrenka: isn't that what was suggested>?
[1:42 PM] aszs: no...
[1:42 PM] aszs: or not by me
[1:42 PM] ttrenka: (where onEach is the actual callback, although that term kind of sucks)
[1:42 PM] aszs: var result = fetch('query');
[1:42 PM] brian_skinner: jaxsphere: i don't think we ever came to a decisions about search/fetch/query terminology -- or about different terms for in-memory vs. client-server
[1:42 PM] ttrenka: right.
[1:42 PM] aszs: result.forEach(myFunc)
[1:43 PM] brian_skinner: jaxsphere: revisiting names is on the agenda
[1:43 PM] ttrenka: we're talking about the changes to that, not just forEach(myFunc)
[1:43 PM] * ttrenka looks at http://dojo.jot.com/dojo.data.api#dojo.data.api.ResultList again
[1:43 PM] ttrenka: sign
[1:43 PM] ttrenka: sigh
[1:43 PM] ttrenka: http://dojo.jot.com/dojo.data.api
[1:43 PM] ttrenka: dojo.data.api.ResultList
[1:43 PM] ttrenka: the different signatures on forEach
[1:44 PM] ttrenka: then the suggestion that we incorporate the controller and the callback function into the following parameter object
[1:44 PM] ttrenka: so that it resembles dojo.io.bind (as an example)
[1:44 PM] aszs: anyways, i don't feel so strongly about this, as long as errcallback is supported
[1:44 PM] ttrenka: yeah, we'd have to support that for sure
[1:45 PM] aszs: not sure about pause/resume
[1:45 PM] ttrenka: ditto
[1:45 PM] brian_skinner: ttrenka: can we go back to the cancel question for a second?
[1:45 PM] ttrenka: but definitely some way of canceling
[1:45 PM] ttrenka: shoot
[1:45 PM] brian_skinner: "I can see result.forEach.cancel()"
[1:45 PM] brian_skinner: "result.forEach({ start:100, end:200, onEach:fn, onError:errorFn, onCancel: fnCancel })"
[1:45 PM] brian_skinner: i don't understand how either of those would work
[1:45 PM] ttrenka: yeah, except you can't call that while the actual forEach method is being run
[1:45 PM] ttrenka: (as I think about it)
[1:46 PM] ttrenka: well, i suppose you can but the timing would be pretty diffcult.
[1:46 PM] aszs: btw, are you proposing start and end being required?
[1:46 PM] brian_skinner: aszs: start/end optional
[1:46 PM] ttrenka: how about we do what aszs suggested before?  if the result of the main callback returns false, forEach gets cancelled?
[1:46 PM] aszs: jaxsphere actually
[1:46 PM] ttrenka: aszs: pretty much everything but the callback Function would be optional, and even that might be optional, depending
[1:47 PM] ttrenka: oh, sorry
[1:47 PM] ttrenka: jaxsphere :)
[1:47 PM] ttrenka: ...one big advantage it gives us is a stable API sig right off the bat though
[1:48 PM] brian_skinner: ttrenka: although if we want to support a UI with a "Cancel" button, the cancel-on-false-return value isn't as convenient as just doing results.cancel()
[1:48 PM] ttrenka: then lets see if we can support both
[1:49 PM] brian_skinner: does the dojo.Deferred object actually have pause/resume methods now?
[1:50 PM] aszs: use case for pause: you execute a query, result stream in, you don't know in advance how much you can display on the page, but when the page if full you want to pause
[1:50 PM] aszs: brian: yes
[1:50 PM] brian_skinner: i don't see that -- I only see a private _pause()
[1:50 PM] aszs: huh, maybe i'm thinking of twisted interface
[1:51 PM] ttrenka: I don't see any reason why we can't add that.
[1:52 PM] ttrenka: but then I also don't see any reason why forEach should be called just once
[1:52 PM] slightlyoff: was just about to say that = )
[1:53 PM] brian_skinner: maybe it'd be good to go off and think about this more -- maybe write up more detailed examples/proposals?
[1:53 PM] brian_skinner: for next week
[1:53 PM] ttrenka: sounds good to me :)
[1:53 PM] brian_skinner: and move on to other questions for this week
[1:53 PM] aszs: you mean if you cancel, and call forEach again, it resumes where it left off?
[1:54 PM] aszs: brian: ok
[1:54 PM] ttrenka: either that, or you can see where forEach left off, and pass it an object that tells it to start from there
[1:54 PM] aszs: but i
[1:54 PM] aszs: but i'd expect cancel to be more final than that
[1:55 PM] aszs: maybe close remote connections etc.
[1:55 PM] brian_skinner: yup, me too
[1:55 PM] ttrenka: how about we don't use the term cancel, but use the term "abort"?
[1:55 PM] ttrenka: for that purpose
[1:55 PM] brian_skinner: what about pause?
[1:56 PM] ttrenka: yeah, it's an interesting problem
[1:56 PM] slightlyoff: having forEach be re-callable seems a weird semantic unless it resets it's "cursor"
[1:56 PM] aszs: yes
[1:56 PM] brian_skinner: yes
[1:56 PM] aszs: i agree
[1:56 PM] aszs: it shouldn't keep state
[1:57 PM] ttrenka: well, part of the deal is that Brian's proposed a start and finish param to forEach
[1:57 PM] aszs: btw, deferred lets you set a oncancelled calback
[1:57 PM] aszs: not sure if that needed here though
[1:57 PM] ttrenka: I don't think we'd preserve a cursor as much as take advantage of using a start and end position
[1:58 PM] aszs: does that required the store implementation to save the results
[1:58 PM] aszs: if so, that seems inefficient
[1:58 PM] ttrenka: isn't that the point of having a result object?
[1:58 PM] ttrenka: as in:
[1:58 PM] aszs: no
[1:58 PM] ttrenka: here's the complete result you asked for.
[1:59 PM] ttrenka: forEach then lets you selectively iterate over it in a controllable, functional way
[1:59 PM] brian_skinner: aszs: the store implementation can do whatever it wants -- that's up to the implementation
[1:59 PM] aszs: if i'm streaming in results there shouldn't be a requirement to save all those results
[1:59 PM] slightlyoff: I'm with aszs on that
[1:59 PM] brian_skinner: aszs: the store can wait to send the query to the server until it knows what the start/end params are
[1:59 PM] ttrenka: the key there though is that it wouldn't be the store saving those results--that's completely up to the implementaion
[2:00 PM] aszs: but if you can call forEach multiple times with different start and end how can know in advance what to save or not?
[2:00 PM] brian_skinner: ah, i see -- no, it wouldn't know
[2:01 PM] ttrenka: nor should it, if you're talking about a streaming data source
[2:01 PM] aszs: brian: if so, than start and end should be part of fetch() not forEach()
[2:01 PM] ttrenka: I would think
[2:01 PM] ttrenka: why can't it be part of both?
[2:01 PM] aszs: ttenka: it can, in response to brian saying the store would wait to sent the query
[2:01 PM] brian_skinner: aszs: right now there's no requirement that fetch() actually execute the query right away
[2:01 PM] ttrenka: gotcha
[2:02 PM] slightlyoff: pick a semantic
[2:02 PM] slightlyoff: any semantic
[2:02 PM] slightlyoff: really
[2:02 PM] slightlyoff: it'll be wrong
[2:02 PM] slightlyoff: and we'll have to fix it
[2:02 PM] slightlyoff: and that's OK
[2:02 PM] slightlyoff: but really, just pick one
[2:02 PM] ttrenka: honestly, we're talking in circles at this point.
[2:02 PM] brian_skinner: ttrenka: +1
[2:02 PM] brian_skinner: we need some more detailed examples/proposals
[2:03 PM] ttrenka: we're talking that result is essentially deferred with a forEach construct that is more powerful than a quick foreach on an array
[2:03 PM] ttrenka: let's just do it that way.
[2:03 PM] aszs: ok
[2:03 PM] ttrenka: ...let's call the callbacks on the result for each major event that might happen in the result lifetime
[2:03 PM] ttrenka: and implement additional things within forEach
[2:03 PM] slightlyoff: (also, I recommend picking the 80% way, so as to reduce the number of cases in which you're wrong)
[2:03 PM] ttrenka: right
[2:03 PM] ttrenka: (no pun)
[2:03 PM] slightlyoff: (but that's a detail)
[2:04 PM] ttrenka: I like what Brian's got for a result API
[2:05 PM] ttrenka: let's add the other parts of aszs' deferred requests to it
[2:05 PM] brian_skinner: ttrenka: i don't understand -- call the same callback function for more than one type of major event?
[2:05 PM] brian_skinner: onComplete, etc.
[2:05 PM] ttrenka: if someone designs it that way...we should allow it.  But we should just put the stubs there.  Like onCancel, onPause, onResume, etc.
[2:06 PM] ttrenka: whatever aszs is talking about for methods on the result object
[2:06 PM] ttrenka: (looking at the API, I see cancel, but I know Adam mentioned more)
[2:06 PM] brian_skinner: but the dojo.Deferred API doesn't allow for more than one type of callback function
[2:06 PM] brian_skinner: there's just
[2:06 PM] aszs: just cancel(), maybe pause() unpause()
[2:07 PM] aszs: two: addCallback and addErrBack()
[2:07 PM] ttrenka: brian: we don't need to actually *inherit* from dojo.Deferred
[2:07 PM] aszs: no
[2:07 PM] tk> small meeting....
[2:07 PM] brian_skinner: okay, I mis-understood
[2:07 PM] brian_skinner: that sounds good
[2:07 PM] brian_skinner: we won't actually *inherit* from dojo.Deferred, we'll just add what makes sense
[2:07 PM] ttrenka: right
[2:08 PM] brian_skinner: +1
[2:08 PM] ttrenka: as long as we make sure we've got decent duck-typing.
[2:08 PM] ttrenka: ;)
[2:08 PM] aszs: yes
[2:08 PM] brian_skinner: okay, on to other agenda items?
[2:08 PM] slightlyoff: someday we'll understand OO...
[2:08 PM] ttrenka: lol
[2:08 PM] slightlyoff: *someday*
[2:08 PM] ttrenka: someone smack that guy :()
[2:08 PM] aszs: maybe javascript will support OO someday
[2:09 PM] ttrenka: alright, I *really* need to take off now.
[2:09 PM] slightlyoff: dear god I hope not = )
[2:09 PM] ttrenka: heh
[2:09 PM] ttrenka: god forbid they actually implement JS 2
[2:09 PM] ttrenka: it'd be the death of the language.
[2:09 PM] brian_skinner: thanks for coming ttrenka
[2:09 PM] ttrenka: thanks for having me
[2:09 PM] aszs: yes, thanks
[2:09 PM] ttrenka: talk to y'all tomorrow
[2:09 PM] brian_skinner: and thanks for the feedback on the agenda questions
[2:10 PM] ttrenka: =)
[2:10 PM] brian_skinner: so...
[2:10 PM] ttrenka: all i care about, really, is trying to keep it simple, flexible and above all forward-looking
[2:10 PM] ttrenka: ;)
[2:10 PM] ttrenka: later!
[2:10 PM] |<-- ttrenka has left freenode ()
[2:10 PM] brian_skinner: dojo.data.api.ReadStore vs. dojo.data.ReadStoreAPI vs. dojo.data.ReadStore vs. dojo.data.ReadAccess ???
[2:10 PM] jaxsphere: dojo.data.ReadAccess
[2:10 PM] aszs: dojo.data.ReadStore
[2:11 PM] brian_skinner: if those are the API files, where do the actual implementations go?
[2:11 PM] jaxsphere: whereever, but not in dojo.data
[2:11 PM] brian_skinner: dojo.data.csv.ReadStore ???
[2:12 PM] brian_skinner: jaxsphere: in some sub-directory of dojo.data ???
[2:12 PM] jaxsphere: or we could do dojo.data.js, dojo.data.xml for the diff impls
[2:12 PM] brian_skinner: so dojo.data is just APIs?
[2:12 PM] jaxsphere: like in the prototoype
[2:12 PM] jaxsphere: that worked well
[2:12 PM] aszs: i have to go soon too, but i don't have much opinon on the names
[2:12 PM] slightlyoff: me either
[2:13 PM] slightlyoff: I'm resigned to someone wanting to change every name in dojo at some point
[2:13 PM] slightlyoff: "just 'cause"
[2:13 PM] brian_skinner: slightlyoff: :-)
[2:13 PM] brian_skinner: aszs: any topics other than names that you want us to hit before you have to go?
[2:13 PM] aszs: but re: save/commit/revert/rollback
[2:13 PM] aszs: as long a pair is chosen i'm ok
[2:14 PM] aszs: i.e. don't have save() alone in an interface
[2:14 PM] brian_skinner: okay
[2:14 PM] brian_skinner: the current wiki page has them as a pair
[2:15 PM] aszs: and i think the pair should be in the WriteStore interface
[2:15 PM] aszs: yes
[2:15 PM] jaxsphere: save/revert ok by me
[2:15 PM] brian_skinner: jaxsphere: you proposed moving them out of WriteStore
[2:15 PM] brian_skinner: might be good to try to come to a decision on that
[2:16 PM] jaxsphere: y
[2:16 PM] jaxsphere: all the ops have to do with manipulating data, set, add, isDirty, etc.
[2:16 PM] jaxsphere: and then we have these ops which deal with data transfer
[2:17 PM] aszs: doesn't isDirty imply some state that gets saved?
[2:17 PM] jaxsphere: similar to fetch/search/retrieve, but for writing
[2:17 PM] jaxsphere: no just that it's changed in some way
[2:18 PM] aszs: yes but then you need to track it...
[2:18 PM] brian_skinner: jaxsphere: are you saying they should not be part of the data store API at all, or they should just be in a different part of the API ?
[2:18 PM] jaxsphere: it seems to me that the search/save/revert should be on the store, not the api's to read/write data values
[2:18 PM] brian_skinner: "on the store" ?
[2:18 PM] brian_skinner: on the store API?
[2:18 PM] jaxsphere: yes, where you have fetch today
[2:19 PM] aszs: jaxasphere: are you proposing another interface?
[2:19 PM] jaxsphere: sync might be another op in future
[2:19 PM] brian_skinner: fetch() is on the ReadStore API -- save() doesn't make sense for a read-only data store
[2:20 PM] jaxsphere: ah
[2:20 PM] jaxsphere: when i saw examples of store.fetch, i was thinking that store was diff that Read, sorry
[2:21 PM] aszs: ok, i gonna go now...
[2:21 PM] brian_skinner: so is save() okay on the WriteStore API ?
[2:21 PM] brian_skinner: aszs: thanks for coming
[2:21 PM] aszs: bye
[2:21 PM] jaxsphere: y
[2:22 PM] jaxsphere: if this is only Read/Write/Result now
[2:22 PM] --| aszs has left #dojo-meeting
[2:23 PM] brian_skinner: jaxsphere: I was thinking of Read/Write/Result as the three most basic parts of the API -- with other stuff to follow later: Notification, Versioning, MetaModel, Controller, DataTypes
[2:23 PM] -->| rcoup (n=rcoup@203-97-179-205.reserved.telstraclear.net) has joined #dojo-meeting
[2:23 PM] jaxsphere: y
[2:23 PM] brian_skinner: a really simple implementation could just implement Read/Result
[2:24 PM] jaxsphere: so naming with this latest set of api's, i like dojo.data.Read/Write/Result?
[2:24 PM] brian_skinner: a simple read-write implementation could just do Read/Result/Write
[2:24 PM] jaxsphere: yep
[2:25 PM] brian_skinner: in an earlier meeting, Tom was confused because he thought the ReadStore wiki page was describing an implementation, not an API
[2:25 PM] jaxsphere: won't need Async now, right?
[2:25 PM] jaxsphere: will want Meta
[2:25 PM] brian_skinner: i'm worred about using a name like dojo.data.Read that doesn't have ".api." or API anywhere in the name
[2:25 PM] jaxsphere: DataType
[2:25 PM] brian_skinner: jaxsphere: right, I think we don't need Async now
[2:26 PM] jaxsphere: there's no ".api" anywhere else in dojo...its implicit
[2:26 PM] brian_skinner: but we do want Meta and DataType
[2:26 PM] jaxsphere: and you could provide some common impls in the dojo.data package that are shared between provider impls
[2:27 PM] brian_skinner: i'm not sure dojo has api description files anywhere else -- we may be doing something new here -- slightlyoff: any thoughts?
[2:28 PM] brian_skinner: jaxsphere: yes, i think some simple common implementations would be good too -- but I also wanted to have api descriptions that are free of implementation baggage
[2:28 PM] jaxsphere: dojo/data/common.js <- contains Read/Write/Result
[2:28 PM] jaxsphere: interfaces
[2:28 PM] slightlyoff: brian_skinner: we haven't had API descriptions, the closest thing is the dojo.dnd.* system
[2:29 PM] brian_skinner: slightlyoff: any suggestions for how to introduce the idea of API descriptions?
[2:29 PM] slightlyoff: brian_skinner: mixins
[2:29 PM] jaxsphere: y
[2:29 PM] brian_skinner: i thought it would be useful to have actual code in SVN for the APIs, so that documentation would get generated
[2:30 PM] slightlyoff: yep
[2:30 PM] brian_skinner: don't mixins serve to mixin the actual implementations?
[2:30 PM] slightlyoff: brian_skinner: yeah, but if you use them as a superclass and redefine the functions....
[2:31 PM] slightlyoff: or you could go all Python/Twisted on us and name it all ISomethingOrOther
[2:31 PM] brian_skinner: so in the superclass you could just have all the functions be not implemented?
[2:31 PM] jaxsphere: declare interfaces as mixins with must implement no ops
[2:31 PM] slightlyoff: jaxsphere: yep
[2:31 PM] slightlyoff: jaxsphere: actually, dojo.unimplemented() calls
[2:31 PM] jaxsphere: right
[2:32 PM] brian_skinner: so then what I did on the ReadStore wiki page is okay, with all the dojo.unimplemented calls?
[2:32 PM] brian_skinner: http://dojo.jot.com/dojo.data.api.ReadStore
[2:32 PM] slightlyoff: yeah
[2:32 PM] jaxsphere: looks good
[2:32 PM] slightlyoff: anyone who wants to implement then needs to at least stub over them
[2:32 PM] brian_skinner: we could just check that into SVN, if we can decide on the file name and the package name :-)
[2:32 PM] jaxsphere: like the doc format too
[2:32 PM] slightlyoff: i.e., you force them to think about it
[2:32 PM] brian_skinner: okay, sounds good
[2:33 PM] brian_skinner: slightlyoff, jaxsphere: so do you have an opinion about whether we want to have "API" or "I" in the name?
[2:33 PM] brian_skinner: or in the package name?
[2:34 PM] jaxsphere: neither
[2:34 PM] slightlyoff: I'm w/ jaxsphere
[2:34 PM] jaxsphere: dojo.data.Read/Write/Result
[2:34 PM] slightlyoff: yep
[2:34 PM] jaxsphere: then my xml impl will be dojo.data.xml.DataStore and mix them in
[2:34 PM] brian_skinner: okay, i stand outvoted -- we'll nix the API part
[2:35 PM] brian_skinner: so, dojo.data.Read or dojo.data.ReadStore ?
[2:35 PM] brian_skinner: or dojo.data.ReadAccess ?
[2:35 PM] jaxsphere: i like the simpler names now that i understand what happened :)
[2:35 PM] jaxsphere: Read/Write/Result
[2:35 PM] * slightlyoff votes for simple
[2:36 PM] brian_skinner: I'm worried that those names will be confusing to people who are looking at this stuff for the first time
[2:36 PM] jaxsphere: you can create a ReadStore by mixin of Read and Result
[2:36 PM] brian_skinner: jaxsphere: I don't see it that way
[2:37 PM] jaxsphere: sorry, mixin and implement Read
[2:37 PM] brian_skinner: a ReadStore implementation *returns* a Result implementation
[2:37 PM] brian_skinner: jaxsphere: right
[2:37 PM] jaxsphere: separate imple of Result
[2:37 PM] jaxsphere: right
[2:38 PM] brian_skinner: so, Read and Write are both implemented by a data store object, and Result is implemented by a separate result object, but there's no clue in the names that Result is different from Read and Write
[2:38 PM] jaxsphere: dojo.data.Read/Write/Result/Meta/Versioning seem straightwforward
[2:39 PM] jaxsphere: i think the term Store actually makes it more complicated
[2:39 PM] jaxsphere: I need to "read" data
[2:39 PM] jaxsphere: I need to "write" data
[2:39 PM] jaxsphere: " " get data Results
[2:40 PM] jaxsphere: whether its a store or an xml data island or an html fragment is going to be what i specify to the Read op
[2:40 PM] jaxsphere: on search/fetch
[2:42 PM] brian_skinner: okay, not sure what to do about the names -- sounds like we each have different takes on what would be best -- Tom and Alex seemed to be voting for shorter names too
[2:42 PM] jaxsphere: they're short, but they still make sense
[2:43 PM] brian_skinner: maybe you or I should write up a quick summary of the suggested short names, and run that by the dojo-dev list to get a feel for whether anybody else has a strong thumbs-up or thumbs-down opinion -- if people don't object to the short names we'll go with the short names
[2:43 PM] jaxsphere: want to mod the wiki?
[2:44 PM] brian_skinner: yup, that'd be good
[2:44 PM] brian_skinner: changing the content on the wiki pages is easy
[2:44 PM] jaxsphere: for fetch/search, the search({search parms}) form makes more sense to me than fetch({query:"",})
[2:45 PM] brian_skinner: i'm a little worried about changing the actual names of the pages -- i'll think about how to handle that
[2:45 PM] jaxsphere: k
[2:45 PM] brian_skinner: okay, on to fetch/search
[2:45 PM] jaxsphere: i can update them now...
[2:45 PM] brian_skinner: jaxsphere: thanks, that'd be great
[2:46 PM] jaxsphere: can we remove AsynchReadStore section for now?
[2:46 PM] jaxsphere: maybe move to a future thoughts page?
[2:46 PM] brian_skinner: yes, let's delete AsynchReadStore section
[2:46 PM] brian_skinner: i don't think we need it at all anymore
[2:46 PM] jaxsphere: also TransactionalStore
[2:47 PM] jaxsphere: dojo.data.Factory is still relevant, right?
[2:47 PM] brian_skinner: how about creating a new wiki page at http://dojo.jot.com/dojo.data.Read to replace http://dojo.jot.com/dojo.data.api.ReadStore, and then having the old dojo.data.api.ReadStore page just be a mostly empty page that tells people to go to the new page?
[2:47 PM] brian_skinner: and likewise for the other pages
[2:48 PM] brian_skinner: i can do that part, if that would be useful
[2:48 PM] jaxsphere: ok
[2:48 PM] brian_skinner: I think both Factory and TransactionalStore are still relevant
[2:48 PM] jaxsphere: is Selection fully baked?
[2:48 PM] jaxsphere: that seems more like an interface for a Controller
[2:48 PM] brian_skinner: Selection is half-baked
[2:49 PM] brian_skinner: it's unclear to me where the selection stuff belongs
[2:49 PM] --| JeffreyH has left #dojo-meeting
[2:49 PM] jaxsphere: in fact, there is already a Selection api for Treev3
[2:49 PM] jaxsphere: that is part of the TreeController :)
[2:49 PM] brian_skinner: in FilteringTable, i think Tom treats some of the selection stuff as data-centric rather than controller-centric
[2:50 PM] jaxsphere: i think Controller,Selection need to move to widgets package
[2:50 PM] brian_skinner: but, yes, probabaly it really belongs in the controller
[2:50 PM] jaxsphere: Binder stays in data
[2:51 PM] brian_skinner: what's Binder?
[2:51 PM] jaxsphere: for Notification, maybe we could come up with a standard topic-space for subscribing data events using the existing pubsub api
[2:51 PM] jaxsphere: single widget property to data value binding (bi-di)
[2:52 PM] brian_skinner: do we need a binder API?
[2:52 PM] jaxsphere: it can go with Controller, but does have a hard dependency on data.Read/Write api's unlike controller
[2:52 PM] brian_skinner: seems like the binders will depend on both the widgets and the data API, yes?
[2:52 PM] jaxsphere: since it's widget related, should prob move with Controller
[2:52 PM] brian_skinner: yes, I would have thought binders and controllers would go together
[2:52 PM] jaxsphere: y
[2:53 PM] brian_skinner: binder doesn't have a hard dependency on the data.Read/Write api's?
[2:53 PM] brian_skinner: how does the binder read data values?
[2:53 PM] jaxsphere: the reason it was in data was that there was not a common data access api, but now that there is, makes sense to move to widget
[2:53 PM] jaxsphere: via data.Read
[2:54 PM] brian_skinner: okay, so a binder is just uses the data.Read apis
[2:54 PM] jaxsphere: changes data values via data.Write
[2:54 PM] brian_skinner: isn't that the way a controller works too?
[2:54 PM] jaxsphere: yes
[2:54 PM] jaxsphere: n
[2:54 PM] brian_skinner: what's different about the controller?
[2:54 PM] jaxsphere: controller doesnt necessarily have to have data api dependency (that's optional)
[2:55 PM] brian_skinner: i see
[2:55 PM] brian_skinner: okay
[2:55 PM] jaxsphere: and controller usually contains many binders or child controllers
[2:55 PM] brian_skinner: okay
[2:55 PM] brian_skinner: so, back to notification for a second
[2:56 PM] brian_skinner: if we can sign off on Read/Result/Write pretty soon, then I think Notification is the next thing to get figured out
[2:56 PM] brian_skinner: that or MetaModel
[2:56 PM] jaxsphere: meta and change tracking
[2:56 PM] brian_skinner: change tracking == versioning ??
[2:56 PM] jaxsphere: once we have a standard way to track changes, we can define a standard place they're published
[2:56 PM] jaxsphere: n
[2:57 PM] jaxsphere: tracking all state changes to data
[2:57 PM] brian_skinner: change tracking == notification of changes ??
[2:57 PM] jaxsphere: its the hook that can optionally be added into all state changing operations to allow changes to be tracked
[2:58 PM] brian_skinner: okay, so it goes hand-in-hand with notification?
[2:58 PM] jaxsphere: we use change objects in the prototype
[2:58 PM] jaxsphere: y
[2:58 PM] brian_skinner: got it -- thanks for the clarification
[2:59 PM] jaxsphere: then we can optionally publish the changes to topics
[2:59 PM] brian_skinner: okay
[2:59 PM] brian_skinner: i'm starting to get tired and hungry -- but I wanted to ask at least a couple more things, if you've got time
[2:59 PM] jaxsphere: ok
[3:00 PM] brian_skinner: one thing -- i was wondering if you ever posted those great dojo.data slides that you made back a couple months ago?
[3:00 PM] brian_skinner: I'd like to point a couple other people at those as intro material
[3:01 PM] jaxsphere: no, i didn't...at this point, the controller and binder pieces are pretty much the same, but the data access/provider section will be diff
[3:01 PM] jaxsphere: we can publish, but will want to bring up to date with the latest api toughts
[3:01 PM] brian_skinner: i see
[3:02 PM] brian_skinner: well, i don't want to add stuff to your to-do list, but let me know if you do update it
[3:02 PM] jaxsphere: ok
[3:03 PM] slightlyoff: gotta go
[3:03 PM] |<-- slightlyoff has left freenode ()
[3:03 PM] jaxsphere: bye alex
[3:03 PM] brian_skinner: bye
[3:03 PM] brian_skinner: just wanted to follow up on something else you mentioned
[3:03 PM] brian_skinner: >	dojo/data/common.js <- contains Read/Write/Result
[3:04 PM] jaxsphere: that's prob wrong
[3:04 PM] brian_skinner: having a common.js seems like a fine idea -- i'd also like to have Read/Write/Result each available separately
[3:04 PM] jaxsphere: common is where we put shared functions
[3:04 PM] brian_skinner: okay
[3:04 PM] brian_skinner: right, i guess it doesn't make so much sense for api files
[3:04 PM] jaxsphere: but for Read/Write/Result we should put in diff files (to reduce footprint with packaging system)
[3:05 PM] brian_skinner: okay
[3:05 PM] jaxsphere: where to put "custom" datastores?
[3:05 PM] brian_skinner: also, wanted to see what you thought about byId() vs. byKey() vs. something else
[3:05 PM] jaxsphere: like Delicious
[3:06 PM] brian_skinner: is a custom datastore really any different from any other datastore implementation?
[3:06 PM] brian_skinner: don't we just have lots of different data store implementations?
[3:06 PM] jaxsphere: would be nice if we had com.delicious or com.flickr.data
[3:07 PM] jaxsphere: rather than packing a bunch of custom provider impls into a single package scope
[3:07 PM] brian_skinner: for datastores that specifically connect to a web service hosted at a single site?
[3:07 PM] jaxsphere: right
[3:07 PM] jaxsphere: for the ones that speak proprietary protocols
[3:08 PM] brian_skinner: we might also have datastores that speak proprietary protocols but that don't connect to individual web sites
[3:08 PM] brian_skinner: oracle-store
[3:08 PM] brian_skinner: for example
[3:09 PM] jaxsphere: y, or atom/rss feed source
[3:09 PM] brian_skinner: in any case, we'll want everything to live somewhere under dojo.data
[3:09 PM] brian_skinner: dojo.data.com.delicious
[3:09 PM] jaxsphere: y, if it's dojo data related code
[3:10 PM] brian_skinner: right, if it's part of the dojo toolkit
[3:10 PM] jaxsphere: dojo/data/custom?
[3:10 PM] brian_skinner: something like that sounds good
[3:10 PM] jaxsphere: dojo/data/custom/atom
[3:10 PM] jaxsphere: dojo/data/atom
[3:10 PM] jaxsphere: i guess we dont need to figure this out now
[3:10 PM] jaxsphere: on the Id/Key thought
[3:11 PM] jaxsphere: i think we'll need to have a way of indicating "key" values
[3:11 PM] jaxsphere: values part of primary key, for uniqueness
[3:11 PM] jaxsphere: identity
[3:11 PM] jaxsphere: but that's prob in the meta api
[3:12 PM] brian_skinner: you mean, like indicating which field of table serve as part of the primary key?
[3:12 PM] jaxsphere: y
[3:12 PM] brian_skinner: yes, I think we'll want that in the meta api
[3:12 PM] jaxsphere: like in a csv file, if you have a column or two that serve to uniquely identify items
[3:13 PM] jaxsphere: eg. there is no "id" column necessarily
[3:13 PM] brian_skinner: right
[3:13 PM] brian_skinner: adam souzis once suggested that byId() and getIdOf() actually belong in the meta api too
[3:13 PM] jaxsphere: how about getIdentity()
[3:13 PM] jaxsphere: I don't like id or key
[3:13 PM] brian_skinner: but I think it makes sense to have some sort of simple method on the dojo.data.Read api itself
[3:14 PM] brian_skinner: since any Read store can implement the simple version -- even if the meta api offers more info
[3:14 PM] jaxsphere: maybe there's a way to get an identity function for an item tuple?
[3:14 PM] brian_skinner: what's an item tuple?
[3:15 PM] jaxsphere: a set of data values (an item)
[3:15 PM] jaxsphere: typed or not
[3:16 PM] jaxsphere: maybe getIdentity() returns a unary function that can be provided by each store, evaling the func passing an item returns a string identity
[3:16 PM] jaxsphere: id, uri,serialized key, etc.
[3:17 PM] jaxsphere: getIdentity(item)
[3:17 PM] brian_skinner: can't store.getIdentity(item) just return some sort of value that uniquely identifies the item, such that store.byIdentity(value) will return the same item?
[3:18 PM] jaxsphere: y
[3:18 PM] brian_skinner: i don't understand the unary function idea
[3:18 PM] brian_skinner: returning a function instead of a value?
[3:18 PM] jaxsphere: store.getIdentity(item)
[3:19 PM] jaxsphere: since provider is implementing Read anyway, yes
[3:19 PM] brian_skinner: okay, so you vote -1 for both byId() and byKey()
[3:19 PM] jaxsphere: y
[3:20 PM] brian_skinner: byIdentity() and getIdentity() instead?
[3:20 PM] brian_skinner: getIdentity() rather than getIdentityOf() ?
[3:20 PM] jaxsphere: propose byIdentity(identifierString), getIdentity(item)
[3:20 PM] jaxsphere: y
[3:20 PM] brian_skinner: okay, that sounds good to me
[3:20 PM] jaxsphere: how do i safely compare two item's to see if they're the same
[3:21 PM] brian_skinner: i'll write something up summarizing all the proposed name changes and post it to dojo-dev
[3:21 PM] brian_skinner: see if we can get buy-in
[3:21 PM] jaxsphere: store.getIdentity(item1).equals(store.getIdentity(item2))?
[3:21 PM] brian_skinner: i was thinking...
[3:21 PM] jaxsphere: or store.compare(item1,item2)
[3:21 PM] jaxsphere: which uses identity internally
[3:22 PM] brian_skinner: item1 === item2
[3:22 PM] brian_skinner: a single item will only ever have one item object handle
[3:22 PM] brian_skinner: if (item1 === item2)
[3:22 PM] brian_skinner: or 
[3:22 PM] brian_skinner: assert(item1 === item2)
[3:23 PM] jaxsphere: ok
[3:23 PM] brian_skinner: i think there's something about that down in the depths of the DataStoreAPI wiki page ;-)
[3:23 PM] jaxsphere: i think there will be a need for a by value compare (eg. diff) at some point
[3:23 PM] brian_skinner: for items or for attribute values?
[3:24 PM] brian_skinner: (strings, numbers, booleans, etc)?
[3:24 PM] jaxsphere: both
[3:24 PM] brian_skinner: i think i understand the value compare, but not the item compare
[3:24 PM] brian_skinner: something for sorting?
[3:25 PM] jaxsphere: that's for versioning
[3:25 PM] brian_skinner: i see
[3:25 PM] jaxsphere: if i need to tell what changed
[3:25 PM] jaxsphere: eg. conflict resolution
[3:25 PM] brian_skinner: yes, that's thorny 
[3:26 PM] jaxsphere: tackle later
[3:26 PM] brian_skinner: +1
[3:26 PM] brian_skinner: one step at a time :-)
[3:26 PM] jaxsphere: so...
[3:26 PM] jaxsphere: assuming the dojo devs love these new apis
[3:27 PM] jaxsphere: next step would be check in of the apis from wiki into the dojo.data package in head
[3:27 PM] jaxsphere: ?
[3:27 PM] jaxsphere: or work this in a branch
[3:27 PM] jaxsphere: head, experimental?
[3:27 PM] brian_skinner: my inclination is to check the apis into head, but mark them as experimental
[3:28 PM] jaxsphere: k that would be good :)
[3:28 PM] jaxsphere: easier for us to work on impls that way
[3:28 PM] brian_skinner: and take the old experimental stuff in dojo.data head and move it out of the way
[3:28 PM] jaxsphere: deprecate?
[3:28 PM] jaxsphere: oh, it was experimental :)
[3:28 PM] brian_skinner: no need to formally deprecate because it was only experimental
[3:28 PM] jaxsphere: right
[3:28 PM] brian_skinner: i thought i might just move it down into dojo.data.old
[3:28 PM] brian_skinner: and then delete it entirely in a few months
[3:29 PM] brian_skinner: once we have a new implementation workign
[3:29 PM] brian_skinner: but, before checking in the new apis, i think we should get everybody signed off on the terminology
[3:29 PM] jaxsphere: i need to call it a night...travelling early tommorrow
[3:29 PM] brian_skinner: okay
[3:30 PM] brian_skinner: where you going?
[3:30 PM] jaxsphere: minneapolis
[3:30 PM] brian_skinner: how long?
[3:30 PM] jaxsphere: 2d
[3:30 PM] jaxsphere: back on friday
[3:30 PM] brian_skinner: have a good trip
[3:30 PM] jaxsphere: thanks!
[3:30 PM] brian_skinner: thanks for staying so long today
[3:30 PM] brian_skinner: much appreciated
[3:30 PM] jaxsphere: np, i had to make up for last week
[3:31 PM] jaxsphere: ;)
[3:31 PM] brian_skinner: see you next week ;-)
[3:31 PM] jaxsphere: I'll make these mods tonight, if you can get those new pgs in place
[3:31 PM] jaxsphere: thanks, ttyl!
[3:31 PM] brian_skinner: i may not manage to make the new pages until tomorrow
[3:32 PM] brian_skinner: feel free to edit the existing pages, and i'll move that over to the new pages
[3:32 PM] brian_skinner: that okay?
[3:32 PM] jaxsphere: ok
[3:32 PM] brian_skinner: thanks!