Resolutions

• Brian to take code from dojo.data.Read/Result/Write pages and check those into SVN head
• propose to move getByIdentity() and getIdentity() out of dojo.data.Read (maybe into dojo.data.Identity)
• propose to add new methods add() and remove() to dojo.data.Write()

Transcript

[1:18 PM] brian_skinner: looks like it's just us two
[1:18 PM] jaxsphere: yep
[1:18 PM] brian_skinner: i didn't put together an agenda
[1:19 PM] jaxsphere: we had the one from last week
[1:19 PM] jaxsphere: err tues :)
[1:19 PM] brian_skinner: http://dojo.jot.com/2006-09-19
[1:19 PM] brian_skinner: plus the questions that Adam raised in his mail today
[1:21 PM] jaxsphere: It sounds like Adam has the api's in svn
[1:21 PM] jaxsphere: I'd like to get access to the same one's he's using
[1:21 PM] jaxsphere: maybe work this like the gfx team is doing
[1:21 PM] brian_skinner: he's working on an RDF implementation of the API
[1:21 PM] jaxsphere: can we get the current proposed API's posted to the contrib list
[1:22 PM] jaxsphere: as a zip
[1:22 PM] jaxsphere: we can update them there as issues are resolved
[1:22 PM] jaxsphere: I'd like to try implementing the xml ds behind these and see what other issues we hit
[1:23 PM] jaxsphere: but dont want code that's out of sync with what u guys are doing
[1:23 PM] jaxsphere: other option is just to put the api's into the datamodel branch in svn?
[1:24 PM] brian_skinner: i'm not actually doing any coding yet -- I wanted to start writing unit tests but haven't found the time -- so no risk of getting out of sync with me!
[1:24 PM] brian_skinner: i don't know that Adam is working in any SVN repository at all
[1:24 PM] brian_skinner: he may be working on his local hard drive
[1:24 PM] brian_skinner: or he may be working in his own SVN repository
[1:25 PM] jaxsphere: I'll send him a reply on contrib and see if he can post the api code to the list
[1:25 PM] brian_skinner: for his Raccoon/Rhizome project, rather than the Dojo SVN repository -- http://www.liminalzone.org/Rhizome
[1:26 PM] brian_skinner: i'd be happy to check the API files into the dojo/data/ directory in SVN head, if you don't think that would be premature
[1:26 PM] jaxsphere: i dont think it is at this point.  i think we need to validate via impls
[1:27 PM] brian_skinner: i know the APIs aren't quite stable, but we could make incremental changes in the SVN API files instead of the wiki API files
[1:27 PM] jaxsphere: until we actually write some code against them (like adam), i cant tell what additional issues there are going to be
[1:27 PM] brian_skinner: yup
[1:27 PM] brian_skinner: okay, i'll do a checkin this afternoon
[1:27 PM] jaxsphere: k
[1:27 PM] brian_skinner: should i just check in dojo.data.Read and dojo.data.Result, or should I also do dojo.data.Write?
[1:28 PM] jaxsphere: Write too
[1:28 PM] brian_skinner: okay, will do
[1:28 PM] jaxsphere: its private branch
[1:29 PM] jaxsphere: so the getByIdentity() function...\
[1:30 PM] jaxsphere: why would it invoke a query?
[1:30 PM] brian_skinner: I was thinking of checkin to head rather than private branch, and just marking the code as experimental -- that way API docs will get generated, and changes will automatically get posted to the dojo-checkins mailing list, and there's more visibility for other dojo developers
[1:30 PM] jaxsphere: i was assuming the string returned would be calculated from the item, source, values, etc.
[1:30 PM] jaxsphere: that's even better
[1:30 PM] brian_skinner: peachy, i'll do that
[1:31 PM] jaxsphere: we're not getting a whole lot of feedback from others outside the gang of 4 or 5... i think its time to try to make it concrete
[1:31 PM] brian_skinner: yup, agreed
[1:31 PM] jaxsphere: once there are ut's and examples, i'm sure we;ll get tons of input :)
[1:32 PM] brian_skinner: i'm planning to do a quick CSV implementation too -- just so that we have a concrete example -- something that can be wired up to different widgets
[1:32 PM] brian_skinner: i think adam was talking about getByIdentity(), not getIdentity()
[1:32 PM] jaxsphere: thats a really good one to start with
[1:32 PM] brian_skinner: getIdentity just returns a string
[1:33 PM] jaxsphere: right, ok
[1:33 PM] brian_skinner: but getByIdentity returns an item
[1:33 PM] jaxsphere: that returns an item, given a string from prev call to getIdentity()
[1:33 PM] brian_skinner: yup
[1:34 PM] brian_skinner: so, if the item happens to be in the cache, then it can return the item immediately
[1:34 PM] brian_skinner: but if not, then it might need to hit the server
[1:34 PM] jaxsphere: so the impl either needs to create a map index of identities so that items can be looked up, or if not not in the map try to pull from remote
[1:34 PM] jaxsphere: ok, gotcha
[1:34 PM] brian_skinner: yup
[1:35 PM] brian_skinner: should be straightforward to implement -- but the return value would be ugly
[1:35 PM] jaxsphere: yeah
[1:35 PM] jaxsphere: in a purely restful approach, each item would have an associated uri when retrieved remotely
[1:36 PM] jaxsphere: but that's not always the case
[1:36 PM] brian_skinner: always return a Deferred?  ...  sometimes return a Deferred?  ...  always return an item synchronously, even if it means waiting on the server response?
[1:36 PM] jaxsphere: perhaps identity functions should be an optional layer
[1:36 PM] brian_skinner: you mean, move getByIdentity() and getIdentity() out of dojo.data.Read, and into something like dojo.data.Identity?
[1:37 PM] jaxsphere: y
[1:38 PM] brian_skinner: that sounds okay to me -- we'd still have the same basic problem with the return values, but pushed out so that fewer people have to think about it
[1:38 PM] jaxsphere: right...kiss for common uc's
[1:39 PM] brian_skinner: okay, we can propose that at the next IRC meeting, or via the dojo-dev list
[1:39 PM] jaxsphere: one can build their own indexes off of the deffered, right :)
[1:39 PM] brian_skinner: i didn't follow that last idea -- can you explain?
[1:40 PM] jaxsphere: as items are recieved in the client, app code that's iterating can cache in a map
[1:40 PM] jaxsphere: however it wants
[1:40 PM] jaxsphere: but it would be up to the app to deal with identity
[1:41 PM] jaxsphere: just for grins, for CSV store, how would you implement getIdentity()?
[1:41 PM] brian_skinner: yup, but that seems a little scary -- the data provider implementation maintaining one cache-map thing, and the client app maintaining another
[1:41 PM] brian_skinner: makes MRU cache management that much harder
[1:42 PM] jaxsphere: y
[1:42 PM] brian_skinner: for CSV store, I was just going to use simple row numbers for getIdentity() -- '1', '2', '3'...
[1:42 PM] jaxsphere: would you offer a private function on the datastore to specify the key columns to use for identity?
[1:43 PM] brian_skinner: yup, a fancier CSV store could do that
[1:43 PM] jaxsphere: i think there's a set of these add'l identity related functions that will make sense to put with Identity.js
[1:43 PM] brian_skinner: but that seemed to start to get into metamodel/schema stuff, which we haven't really talked about API for
[1:44 PM] brian_skinner: yup, good point
[1:44 PM] jaxsphere: right, identity will prob require Read/Write/Meta api's
[1:44 PM] brian_skinner: another reason to push identity out fo dojo.data.Read
[1:44 PM] jaxsphere: yep
[1:46 PM] brian_skinner: i'm worried that even our simplest methods, get() and getValues() might actually need to trigger server access sometimes, just like getByIdentity() sometimes does
[1:46 PM] brian_skinner: if the user is navigating a complex object graph
[1:46 PM] jaxsphere: Let's hold this agenda item until weve each done a first pass prototoype on the current proposed apis:
[1:46 PM] jaxsphere: sign off on some APIs (or is it too early for this?)
[1:46 PM] jaxsphere:     * Read and Result
[1:46 PM] jaxsphere:     * Write
[1:46 PM] brian_skinner: okay
[1:47 PM] jaxsphere: what was the problem with Write api and saving single value?
[1:47 PM] jaxsphere: err adding
[1:47 PM] brian_skinner: example...
[1:47 PM] brian_skinner: books and authors
[1:48 PM] jaxsphere: child collections and references?
[1:48 PM] brian_skinner: an author can write many books -- a book can have a second author (more than one author)
[1:48 PM] brian_skinner: if TheStand is a book
[1:49 PM] brian_skinner: var authors = store.getValues(TheStand, "authors");
[1:49 PM] brian_skinner: then authors.length == 1
[1:49 PM] brian_skinner: authors[0] == StephenKing
[1:50 PM] brian_skinner: how do I add a second author?
[1:50 PM] |<-- DojoLog has left freenode (Read error: 104 (Connection reset by peer))
[1:50 PM] jaxsphere: and authors is an object with its own props
[1:50 PM] jaxsphere: or just string?
[1:50 PM] brian_skinner: authors is just a simple array
[1:50 PM] brian_skinner: StephenKing is an item
[1:51 PM] brian_skinner: var name = store.get(StephenKing, 'name')
[1:51 PM] jaxsphere: ok, add/remove on multivalued attributes (primitives)
[1:51 PM] brian_skinner: ?
[1:52 PM] jaxsphere: the authors is an array of strings, owned as part of the book item
[1:53 PM] brian_skinner: okay, that might be a good simpler case to start with
[1:53 PM] jaxsphere: or... is authors an array of references to Authors (owned by Book) and from the Authors you can get their names
[1:53 PM] brian_skinner: yes, that's the case I was thinking about
[1:53 PM] jaxsphere: from an author, you can add/remove booksAuthored
[1:53 PM] brian_skinner: yup
[1:54 PM] jaxsphere: a collection of Books (the opposite end of the relationship)
[1:54 PM] jaxsphere: Handling relationships like these require Meta package
[1:54 PM] brian_skinner: in RDF stores, and in OpenRecord, you can set up "inverse" attributes -- so that the values of booksAuthored and authorOf are automatically kept in synce
[1:54 PM] jaxsphere: Maybe a Relations module?
[1:55 PM] brian_skinner: but, ignoring the "inverse" thing for now
[1:55 PM] jaxsphere: well, handling inverse is very common
[1:55 PM] brian_skinner: let's just say some attribute has a more than one value -- how do you add a new value?
[1:55 PM] jaxsphere: on 1-many
[1:55 PM] jaxsphere: you need an add/remove op
[1:55 PM] brian_skinner: doesn't really matter if the values are literals or object references
[1:55 PM] -->| DojoLog (n=stats@reigndropsfall.net) has joined #dojo-meeting
[1:56 PM] jaxsphere: but its not just multi valued
[1:56 PM] jaxsphere: also, Employee.businessAddress->Address
[1:57 PM] brian_skinner: if the employee only has one businessAddress, then we already have API for that
[1:57 PM] jaxsphere: this is a "set" for a relationship between objs.  If the relationship is one of ownership, a backreference needs to be set
[1:57 PM] brian_skinner: yup
[1:57 PM] jaxsphere: but how do you know that it's a special ownership relationship without additional metadata
[1:58 PM] jaxsphere: eg. parent/child collection relationships
[1:59 PM] brian_skinner: the data provider implementation could do hande the backreference, even without a metadata API, if the data provider was hard-coded to know about that, or if it was reading metadata info from an RDBMS schema, even if that metadata wasn't exposed in any dojo.data API
[1:59 PM] jaxsphere: we need to add add90 and remove() ops to Write
[1:59 PM] jaxsphere: alonside set
[1:59 PM] brian_skinner: yup, i think we should maybe add add() and remove()
[2:00 PM] brian_skinner: but that raises a couple more questions...
[2:01 PM] brian_skinner: if there are multiple values, are those values ordered -- does add() just append the new value to the end of the list, or does add() allow you to specify where to put the new value in the list
[2:01 PM] brian_skinner: first author, second author, third author
[2:02 PM] jaxsphere: right, addFirst, addAfter,...
[2:03 PM] jaxsphere: now that i konw what the agenda bullet was about, i'll go back through the prototype...  Let's discuss this more next tues
[2:03 PM] brian_skinner: right, or maybe -- add({after: })
[2:03 PM] jaxsphere: add({at:0})
[2:03 PM] brian_skinner: yup
[2:04 PM] brian_skinner: okay, we'll put that on Tuesday's agenda
[2:04 PM] jaxsphere: i've got a hard stop today at 5
[2:04 PM] brian_skinner: okay
[2:04 PM] brian_skinner: isn't it past 5:00 now>?
[2:04 PM] jaxsphere: yep
[2:04 PM] jaxsphere: :)
[2:05 PM] brian_skinner: okay, see you tuesday :-)
[2:05 PM] jaxsphere: i'll try to do some coding this weekend
[2:05 PM] jaxsphere: sounds good, ttyl!
[2:05 PM] brian_skinner: i'll check in the APIs -- hopefully today
[2:05 PM] jaxsphere: k