Agenda Item 1:  Status:

• Status on XmlStore and CsvStore from respective porters.
  • Jared: I'm trying to sort out our dependencies on dojo.=dom and what is going on with dojox.
  • XmlStore? will now go into dojox because of dojox.dom dependency
  • dojox.dom code will be reviewed with trenka before commit.
  • DOH is hacked to run in dojox, and partial port of dom in place.
  • port of XmlStore? should be ready soon.
    

Questions from msmith:

• Q1: Without the "./", all of my dojo.require() statements were failing. Is the 0.9 trunk in a workable alpha stage? Am I supposed to be developing this in the 0.9 trunk, or should I stick to 0.4.2?

Try using this special svn view...
http://svn.dojotoolkit.org/dojo/view/anon/all/trunk

• Q2: I also have a question regarding the Identity API. The Remote store implements Identity, but doesn't include it in the getFeatures object. The same goes for the old CsvStore. Should the new CsvStore implement dojo.data.api.Identity?

Row number identity will be added to CsvStore.

• Q3: Following the pattern of the JsonItemStore, should the CsvStore be able to accept a data string (as opposed to a URL) containing the CSV data?

Include both a data string param and a url param options as ways of initializing CSV store

• Q4: From what I understand, the CsvStore does not support a query parameter to the fetch function. It seems that CSV data can not be filtered during this operation. That is, the entire file must be fetched. Is this correct?

Since CsvStore? was written, we've now mandated that all stores must implement find. In this case, it will be a local filter, see dojo.data.util.filter for example that jared used in Json store.  Filter on field, value, *,?
tests/data/util.js has tests of using the pattern match generator as another example.
assume there is always a header field containing attr names for now.  Future versions or extensions of CSV store could deal with csv data with no header (eg. create field names for each column, field0,field1,...,fieldn)

CsvStore? query syntax should match that of JsonItemStore? 

eg. something like,

query:{author:"King*"} // All rows with field author                                         

                       // that starts with King

- or -

query:{department:"Marketing",name:"Jones"} 

• Q5: Is there any preference of the internal representation of the data? The old CsvStore kept the data in a JSON structure mandated by the RemoteStore, but I see no reason to change this structure.

Example:

         *     { "1": {"Title":["Alien"], "Year":["1979"], "Producer":["Ridley Scott"]},
         *       "2": {"Title":["Blade Runner"], "Year":["1982"], "Producer":["Ridley Scott"]}
         *     }
If no one has any objections, I'll leave it in this structure.
Drop this more complex structure, and use arrays of array values, with a header array. (see Brians note)

• Q6: What's the process for submitting the work that I've done? Attach it to the trac ticket?

Issues identified:  jared/brian-DOH on Rhino test runner needs the ability to work with xhrGet rather than just strings in test code.

Agenda Item 2:  To Be Determined. 

1. More work on the path accessors?
   1. Deferred for later discussion.
      
2. Discuss a bit more on the write api?  There were concerns about the name of the function (save(), which implies a write and close).
   1. Deferred for later discussion
      
3. In the Write API, consider changing the spec for loadItem, to change it from sync to async? And if we make that change, then we need to figure out what it should return, or what callback args it takes.
   1. This should be made async. 
      

loadItem({item: item, onItem: foo, onError: bar, scope: bah});
Documentation should state that the onItem and onError functions will only be called if isItemLoaded() returns false.  Otherwise the callbacks are ignored.  This is for efficiency of simple store impls that load everything into memory, this becomes effectively a no-op function.

1. Start discussing the data bindings project being prototyped?  (dojox.wires)
   1. Not yet.  We'll have user's guide and code ready this thursday.  We could use the dojo.data meeting slot to begin dojox.wire discussion though
      
2. Should we start a dojo.data to-do list, for keeping track of things like this recent suggestion from Chris:
   
   • One other thing to consider for the referencing-in case for dojo.data store implementations... We should provide a best practice store implementation that illustrates how to implement  remote calls for child items, as well as how cached child items can be "freed" if necessary.
   • The todo list would work well as a wiki page to start.  As items are agreed that it will be done, they should then be opened as TODO trackers.
     
3. We've been storing these meeting agendas and other working notes on the old dojo.jot.com wiki. Are we supposed to be migrating the dojo content away from that site, and over to someplace on the new drupal site (like http://www.dojotoolkit.org/developer/notebook )?
   1. This needs to happen too.  JaredJ? said he'll look into how digit is formatting theirs and do something similar.  Will try to start migrating items this week.
      
4. Other items.

---

Minutes:

    <msmith>    i'm here.
    -->|    |ccmitch| (n=kvirc@cpe-024-211-158-152.nc.res.rr.com) has joined #dojo-meeting
    <brian_skinner>    we could wait a few minutes for chris, and take that time to try to answer some of msmith's questions from this morning
    <brian_skinner>    oops, too late!
    <|ccmitch|>    hi!
    <brian_skinner>    hi |ccmitch|
    <jared_j>    msmith sent some questions? I must have missed them.
    <msmith>    sent them in an email just a couple of hours ago...
    <msmith>    i figured they might make for some good topics during this meeting.
    <jared_j>    Ah, okay. I see it now with Brian's reply.
    <|ccmitch|>    can you post them on the wiki page?
    <jared_j>    His questions?
    <|ccmitch|>    y
    <msmith>    i'm not sure that i have write access to the wiki... i have a drupal account, but i never got on the dojo.jot.com wiki
    <jared_j>    I can post them, sec.
    <jared_j>    Posted! Okay, question one with regards to using dojo 0.9
    <jared_j>    It should generally work okay. Buy I think I have a theory as to why you might be failing.
    <msmith>    yes, i didn't have much luck with it.
    <jared_j>    What is your directory structure on disk?
    <jared_j>    (This may or may not be an actual bug, I'm not certain, but I have a theory)
    <msmith>    i've sync'ed with svn to two directories: /www/js/dojo_0_4_trunk and /www/js/dojo_0_9_trunk
    <msmith>    does the root need to be named 'dojo'?
    <jared_j>    Yes.
    <jared_j>    Try syncing to this svn, it's easier...
    <jared_j>    http://svn.dojotoolkit.org/dojo/view/anon/all/trunk
    <jared_j>    That'll give you a root view of dojo, dijit and dojox.
    <brian_skinner>    ah, thanks for that link -- i needed that too
    <|ccmitch|>    should add in util as weel
    <jared_j>    You should be able to run the tests and such out of there fine.
    <jared_j>    That gets util too, yes
    <jared_j>    It's a toplevle view of all of 0.9
    <msmith>    hmm... okay. is that any different than just http://svn.dojotoolkit.org/dojo (which also includes trunk, dojo, dijit, dojox)
    <jared_j>    There are differences, I believe
    <jared_j>    The link I posted was the one I was told to use.
    <jared_j>    It does a bunch of aliasing of dirs in the repository to a much easier view.
    <msmith>    okay. that sounds good to me.
    <jared_j>    Can you try it real quick and see if it works for you?
    <msmith>    I'm not at home right now. I'll have to try it later this evening.
    <jared_j>    Ok
    <jared_j>    Questionj #2. Identity API.
    <jared_j>    I haven't looked at the old CsvStore in a while, but I know the JsonItemStore does something a little creative with getIdentity
    <jared_j>    Basically, the JsonItemStore adds in to its getFeatures that it implements Identity when the data provided to it specified an attribite that acts as an identity
    <jared_j>    CsvStore might be doing something similar (I haven't looked, though). Brian?
    <brian_skinner>    the JsonItemStore is complicated because it may or may not offer the Identity features, depending on the contents of the data file
    <brian_skinner>    but that won't apply to CsvStore
    <jared_j>    Okay, no Identity for CsvStore, easy enough, then. :)
    <brian_skinner>    here's the answer i sent in my mail to Jared...
    <brian_skinner>    Good question. Let's see what Jared thinks on that one. I could go either way on whether the new CsvStore should implement thedojo.data.api.Identi ty methods.
    <brian_skinner>    On the one hand, I think it would be fine for the CsvStore to not support the Identity API at all. That would make the CsvStore super simple, which would make it a good introductory example to use in the first section of any tutorials about dojo.data and the Read API.
    <brian_skinner>    On the other hand, it would be easy to have the CsvStore implement the Identity API by simply using the row number of each item as the identity.
    <jared_j>    Well, hm.
    <|ccmitch|>    seems that it could be optional as well
    <jared_j>    If you can use the row for the identity..
    <|ccmitch|>    if you specify a set of fields to use for identity
    <jared_j>    Could we set it as a constructor param? rowIdentity: true, or somesuch?
    <jared_j>    Or a particular field?
    <brian_skinner>    i think it would be okay to simply not support the identity api in CsvStore
    <jared_j>    We can always add that later too if we really need it
    <|ccmitch|>    +1
    <jared_j>    That doesn't seem required for first pass.
    <brian_skinner>    or, if we do have it, i think we should keep it really simple
    <brian_skinner>    like, just the row number
    <jared_j>    Row number is super simple, yeah. :)
    <jared_j>    I'd say either that, or nothing at all.
    <msmith>    either way is fine by me. i think brian made some good arguments for both sides.
    <brian_skinner>    i'm game either way
    <jared_j>    If you think you can do it by row easily, msmith, then go for it. :)
    <msmith>    is it up to me then? or do we come to a consensus?
    <msmith>    okay. Identity by row, then.
    <|ccmitch|>    go for it
    <jared_j>    Question #3: Parse by string instead of just by URL.
    <|ccmitch|>    CsvStore will be in dojox as well, right?
    <|ccmitch|>    not dojo core
    <jared_j>    String makes writing tests easy that can even run in Rhino.
    <jared_j>    Right
    <brian_skinner>    |ccmitch|: yup, in dojox
    <|ccmitch|>    so do we have an answer to the dojox questions to begin working there?
    <jared_j>    ccmitch: Not yet.
    <brian_skinner>    for the record, here were my thoughts on the string param...
    <brian_skinner>    On the one hand, it would only take a couple lines of code to add that feature, it would make the CsvStore more consistent with the JsonItemStore, and it might make it easier to write tests for the CsvStore.
    <brian_skinner>    On the other hand, adding that feature makes the CsvStore code more complicated for anyone who's trying to read and understand it, which makes it less good as an introductory example. Also, it's hard for me to imagine much demand for that feature in real world use. In the case of CSV data, I think mostly people just want to read from files, whereas with JSON data it's easy to imagine...
    <msmith>    for now i'm developing the CsvStore in core... but that's just locally. I can move it once dojox is ready.
    <brian_skinner>    ...wanting to read from a file or wanting to pass in some pre-processed data object.
    <jared_j>    ccmitch: I would recommend msmith can start it as if he was just working on dojo, and we move it when we know more.
    <jared_j>    msmith: That would be my rrecommendation to do too.
    <msmith>    jared_j: good. thanks.
    <jared_j>    As an aside: I've been prototyping around in the dojox tree a bit. I've hacked up Alex's runner and have tests running out of it now as a separate module.
    <msmith>    brian has a good point here that adding the string input feature will be very simple.
    <jared_j>    But it's really not a real solution.
    <jared_j>    msmith: If you can do it easily and in away that's not complicated, it has one advantage with regards to tests: You can run it in rhino. xhr mode only works when you're running in a browser.
    <brian_skinner>    jared_j: if we don't have string input, then in Rhino will the unit tests just fail? does Rhino not have the ability to read from a file?
    <jared_j>    It fails on the xhrGet calls
    <jared_j>    Unknown function
    <brian_skinner>    doh
    <msmith>    okay, that sounds like a good enough reason to me.
    <brian_skinner>    but i guess that ugly-ifies all the unit tests
    <brian_skinner>    bummer
    <jared_j>    What I did for jsonItemStore tests was put in a: if(dojo.isBrowser){do xhr}else{do js object way}
    <brian_skinner>    jared_j: that sounds good
    <jared_j>    Alternatively ... we *could* see if we could hack in a way for dojo to understand xhrGet
    <jared_j>    I mean, heck, in java that could be mapped to UrlConnection. ;)
    <brian_skinner>    and then you basically end up with two copies of the test data -- one in the file and one in test code?
    <jared_j>    brian_skinner: Yeah, it's a bit sucky, but it was the only way to hget rhino and browser both running the tests.
    <brian_skinner>    it would be great if xhrGet could be made to work in Rhino
    <msmith>    the test code could read the file to load the datastore with the string text of the file. that would eliminate the duplicate copy.
    <jared_j>    msmith
    <jared_j>    msmith: How would the testcode read the file without xhr support at all?
    <msmith>    oh wait... i see. the test code can't read the file.
    <jared_j>    Right. :)
    <msmith>    lol
    <jared_j>    Therein lies the rub.
    <jared_j>    Who knows rhino well and/or how to extend it?
    <brian_skinner>    i'm not sure
    <|ccmitch|>    need rhino xhr (on java)
    <jared_j>    Because there *should* be a way to map dojo.xhrGet() to some java functions.
    <msmith>    you would think so.
    <brian_skinner>    yup, seems like a dojo.hostenv thing
    <|ccmitch|>    i've noted this as an issue for alex
    <jared_j>    It would ultimately be something like: new URLConnection(), read the connection, close, return data, blah.
    <brian_skinner>    you could try pinging the contributors list and see if anybody has thoughts about it
    <brian_skinner>    or just try alex
    <jared_j>    I mean, I've implemented a wget like ANT task before which is more or less like doing an xhr. :)
    <jared_j>    Anyway.
    <|ccmitch|>    Q4: From what I understand, the CsvStore does not support a query parameter to the fetch function. It seems that CSV data can not be filtered during this operation. That is, the entire file must be fetched. Is this correct?
    <jared_j>    brian?
    <|ccmitch|>    y
    <brian_skinner>    Right, the old CsvStore didn't support any sort of query at all. It might be really easy to add support for filtering, using Jared'sdojo.data.util.filte r code. If CsvStore could do simple filtering, that would make it possible to bind a CsvStore to the ComboBox widget, which might make for a good example.
    <brian_skinner>    And I think we may have had a meeting resolution where we said that all datastores are supposed to implement filtering, but I don't remember. Hopefully Jared will have an inclination one way or the other.
    <jared_j>    Well, honestly, it would be good if it can do filtering
    <|ccmitch|>    yes, we did say that. need local impls of filter
    <jared_j>    filter on field, value *, maybe.
    <brian_skinner>    does the dojo.data.util.filter code make that easy to add for CsvStore?
    <jared_j>    Should be. The filter API just gives you the way to gen the regexp pattern that matches some wildcard/? filtering.
    <brian_skinner>    i see
    <jared_j>    You then just do a: string.match(regexp) !== null
    <brian_skinner>    and then you still need to "parse" the query to see which attributes are being filtered on?
    <jared_j>    I had more thna that before, but Adam Peller didn't like it and asked it to be remoived because doing the above is usually just one line in your store. Function wasn't needed.
    <msmith>    jared_j: what is "string" defined as in string.match(regexp) !== null?
    <jared_j>    Any javascript string
    <jared_j>    Look in tests/data/util.js (It has tests of using the simple filter pattern match generator
    <jared_j>    What would the query look like, then?
    <msmith>    what i mean is, should the regexp match a single line in the CSV input or the entire file, or what?
    <jared_j>    Single item
    <jared_j>    What composes a single item in the CsvStore?
    <jared_j>    the set of fields for the row?
    <brian_skinner>    a single item is a row in the file
    <jared_j>    Which is N number of fields?
    <brian_skinner>    each field is an attribute value
    <jared_j>    Then the query could just be:
    <jared_j>    { field:<some field number> value:"some*?pattern"}
    <jared_j>    And that should look in the identified field # and match the value of that field against that pattern
    <jared_j>    Or somesuch.
    <brian_skinner>    yup, but i think we should used named fields, instead of numbers
    <brian_skinner>    so...
    <jared_j>    Named fields is even easier if we can
    <brian_skinner>    { field:"author" value:"some*?pattern"}
    <jared_j>    Actually.
    <msmith>    named fields, assuming that the first line in the file contains the headers, right?
    <brian_skinner>    yup
    <jared_j>    {author:"some?*pattern"}
    <|ccmitch|>    i think you need both dont you?
    <msmith>    should we support both named fields and numbered fields?
    <|ccmitch|>    or else have option to create field names (field1,field2,field3...)
    <|ccmitch|>    for data that does not have header row
    <jared_j>    That's how JsonItemStore does it {attr:"Some pattern"} for filtering.
    <jared_j>    ccmitch: Probably needs that at some point, yes.
    <brian_skinner>    |ccmitch|: a more full-featured CsvStore should have support for both types of CSV files -- the ones with a header row and the ones without
    <jared_j>    If you follow the JsonItemStore pattern of attr:valuepattern, then ComboBox should *easily* be able to hook to it.
    <brian_skinner>    but i think our old CsvStore always assumed that there was a header row
    <brian_skinner>    and i think that's fine for now
    <jared_j>    I think the question then just becomes: How complex do we want to make the store?
    <brian_skinner>    simple
    <jared_j>    Too complex === hard for people to grasp.
    <|ccmitch|>    assume theres a header for now
    <brian_skinner>    i think it exists more as an example than as a store that will be heavily used
    <jared_j>    It should be easy enough to enhance it later to allow field definitions anyway, I would think.
    <jared_j>    Part of the constructor call or somesuch.
    <brian_skinner>    yup
    <brian_skinner>    okay, so the CsvStore query syntax should match the JsonItemStore query syntax
    <brian_skinner>    so that's something like:
    <brian_skinner>    query:{author:"King"}
    <brian_skinner>    ?
    <jared_j>    query:{author:"King*"} // All athors that start with King
    <jared_j>    Or rather, all rows where field author has value that starts with King
    <brian_skinner>    or query:{department:"Marketing", name:"Jones"}
    <jared_j>    Right
    <jared_j>    msmith: Make sense?
    <brian_skinner>    and then in practice hopefully that may only take a few lines of code to implement, with dojo.data.util.filter already available
    <jared_j>    Should be 1-2 lines roughlyin the store to do it.
    <|ccmitch|>    btw, wiki page is being updated with answers
    <brian_skinner>    thanks |ccmitch|
    <jared_j>    JsonItemStore in containsValue, for example, just does:
    <jared_j>    if(typeof value === "string" && typeof possibleValue === "string"){
return (possibleValue.match(dojo.data.util.filter.patternToRegExp(value)) !== null);
}else{
//Non-string matching.
if(value === possibleValue){
return true; // Boolean
}
}
    <jared_j>    And that was it to get filtering with the store.
    <brian_skinner>    cool
    <|ccmitch|>    Q5?
    <brian_skinner>    and then for the query implementation, you just loop through all the query args and call containsValue() ??
    <jared_j>    Against the list of items in the store, yep.
    <msmith>    so in this case, we need to do a match on each possible attribute value, not just the whole item.
    <brian_skinner>    |ccmitch|: i think we lost msmith for a minute
    <brian_skinner>    msmith: yup
    <jared_j>    Right.
    <msmith>    [back -- had to step away for a minute, but i'm caught up]
    <brian_skinner>    well, in the case of the CsvStore, you know that each attribute only has one value
    <jared_j>    Basically, you'll identify which field to look at, then scan the store's item set on that field and check the values.
    <msmith>    okay, i think that answers my question, then.
    <jared_j>    So yeah, with just one value per attr and you know what attr to look at, it'll be quick.
    <|ccmitch|>    q5: that structure seems ok for csv
    <jared_j>    So, Q5?
    <brian_skinner>    |ccmitch|: may I update the wiki page to remove the query example that looks like this: {field:<somenamedfield> value:"some*?pattern"}
    <|ccmitch|>    y
    <brian_skinner>    since we've now said the query format should match JsonItemStore
    <brian_skinner>    will do
    <brian_skinner>    ...
    <jared_j>    That structure looks okayish, though if we did identity we might want to create a special field that contains the row.
    <brian_skinner>    on Q5 i had a long response...
    <brian_skinner>    Okay, here's the one question where I do actually have a strong opinion. I think that the RemoteStore JSON structure is not a good match for what the CsvStore needs. For the CsvStore, the RemoteStore JSON structure is overly complicated, and it will eat memory unnecessarily. I suggest using this structure instead:
    <brian_skinner>    var items = [
    <brian_skinner>    ["Alien", "1979", "Ridley Scott"],
    <brian_skinner>    ["Blade Runner", "1982", "Ridley Scott"]
    <brian_skinner>    ]
    <brian_skinner>    And then for implementing the getValue() method, you would want a way to easily find the array index associated with each attribute name, so a key like this would be useful:
    <brian_skinner>    var attributeIndexes = {"Title":0, "Year":1, "Producer":2};
    <brian_skinner>    And then the getValue() method could look something like this:
    <brian_skinner>    getValue: function(item, attribute, defaultValue) {
    <brian_skinner>    var attributeIndex = attributeIndexes[attribute];
    <brian_skinner>    return (item[attributeIndex] || defaultValue);
    <brian_skinner>    }
    <brian_skinner>    And getValues() would just be:
    <brian_skinner>    getValues: function(item, attribute) {
    <brian_skinner>    return [this.getValue(item, attribute)];
    <brian_skinner>    }
    <msmith>    brian's agrument does make the CsvStore quite a bit simpler, even though the support for the more complex structure is already there.
    <msmith>    i'm inclined to take brian's suggestion here.
    <jared_j>    Just read Brian's comments. I'm also inclined to agre
    <|ccmitch|>    y, use offset for row
    <brian_skinner>    in the interests of simplicity, i'd vote for just deleting the extra methods that do the conversion to the more complex structure
    <jared_j>    The format itself is simple, no need to do a more complex structure than an array of arrays. of simple values
    <|ccmitch|>    use json store for objects with objects
    <jared_j>    Plus building Brian's format would be cheaper than the the RemoteStore more complex one, I woudl think
    <jared_j>    It's just a loop of splits and pushes.
    <|ccmitch|>    y
    <jared_j>    Well, maybe
    <jared_j>    What happens if you have one of the separators in your value? :)
    <brian_skinner>    jared_j: you'd like to think it would just be a simple loop of splits and pushes, but it turns out that all the special character handling for CSV is a pain
    <brian_skinner>    yup
    <jared_j>    Then you need to walk the string char by char and watch for the escapes
    <jared_j>    Same sorta thing I did for my filter generator.
    <brian_skinner>    in reality, CSV files can look like this:
    <brian_skinner>    Title, Year, Producer
    <brian_skinner>    City of God, 2002, Katia Lund
    <brian_skinner>    Rain, 2001, Christine Jeffs
    <brian_skinner>    2001: A Space Odyssey, 1968, Stanley Kubrick
    <brian_skinner>    "This is a ""fake"" movie title", 1957, Sidney Lumet
    <brian_skinner>    Alien, 1979 , Ridley Scott
    <brian_skinner>    "The Sequel to ""Dances With Wolves.""", 1982, Ridley Scott
    <brian_skinner>    "Caine Mutiny, The", 1954, "Dymtryk ""the King"", Edward"
    <msmith>    jared_j: CSV does support excapes. If a separator is in your value, it must be within quotes.
    <jared_j>    Then yeah, you can't use string.split
    <brian_skinner>    but the code for that parsing is already written and seems to mostly work
    <jared_j>    You'll have to parse the bugger.
    <msmith>    yes, the parsing code is already done.
    <jared_j>    Good enough. Reuse it. :)
    <msmith>    and drop the complex structure. we'll stick to the array of arrays.
    <jared_j>    msmith: Right
    <msmith>    okay, i think that covers all of my questions for now.
    <brian_skinner>    Q6?
    <jared_j>    Chris: On your comment on issues. Make sure you state it's running DOH with Rhino.
    <jared_j>    DOHJ in browser is fine with xhr.
    <|ccmitch|>    roger
    <jared_j>    Q6: What Brian said in his e-mail.
    <jared_j>    Attach a patch or alternatively mail it to the list noted. :)
    <msmith>    i appreciate your patience as I'm trying to walk in on the middle of the implementation of this project. I know you guys have done a lot of groundwork that i wasn't a part of.
    <msmith>    about Q6: thanks. that sounds good.
    <jared_j>    msmith: Not a problem. I was in your shoes three months ago.
    <jared_j>    msmith: We appreciate the help, questions are not a bother.
    <msmith>    jared_j: oh. i figured you'd been working on this longer than that.
    <jared_j>    brian_skinner and ccmitch are the long-timers on this. I'm sorta new (though not by much now)
    <jared_j>    Now, quickie status on XmlStore. I'm trying to sort out our dependencies on dojo.dom and what is going on with dojox.
    <jared_j>    Once I have those port should be easy, I believe.
    <|ccmitch|>    XmlStore will now go into dojox
    <jared_j>    I've gotten D.O.H. hacked and running out of dojox and I'm testing a partial port of dojo.dom to dojox.dom
    <brian_skinner>    sounds good
    <jared_j>    The basic functions w euse. I'll need to get ttrenka to review the port afterword if he's okay with it.
    <jared_j>    Other than that, all XmlStore needs are string(there), and xhr (there). And it shoul dport pretty quickly.
    <jared_j>    Would you want to see an interim version of it, Brian? (When I get a dojox env working with it)?
    <msmith>    all: thanks again for your time. I'll be inactive the rest of the meeting, but I'll still be around. Ping me if you need anything. (ALL CAPS might do to get my attention.) :)
    <brian_skinner>    either way is fine by me -- if you send me an interim version i can take a look -- or reel free to just check it in, and i can look at the checked in code
    <brian_skinner>    msmith: thanks for taking time to make it to the meeting!
    <msmith>    brian_skinner: my pleasure.
    <brian_skinner>    on to agenda item 2?
    <|ccmitch|>    I made a note on a2.4
    <|ccmitch|>    can we start with 5&6
    <|ccmitch|>    We need to create a new section on drupal site
    <brian_skinner>    for meeting notes and whatnot?
    <|ccmitch|>    to store the agendas, notes, etc. Seems that todo's should be tracked as feature defects in tracker
    <brian_skinner>    sounds good
    <|ccmitch|>    actually, there's a todo type, right?
    <|ccmitch|>    in tracker..
    <|ccmitch|>    there's Developer->Dijit today
    <jared_j>    Agreed we need to create a new section. anyone have any opinions on the format? Or want me to 'wing' it on a possible format and post it as a suggestion somewhere?
    <|ccmitch|>    Why not Developer->Data Access
    <|ccmitch|>    and Developer->Wires
    <brian_skinner>    sounds good
    <brian_skinner>    jared_j: winging it on the format seems fine
    <brian_skinner>    or copy what's been done for Dijit, if that works
    <jared_j>    Dijit wasn't there when I looked last. I'll look at what they did now and follow something similar, I imagine
    <jared_j>    Consistency and all that.
    <brian_skinner>    :)
    <|ccmitch|>    i think we should wait a bit before gettin gback on item 2.1
    <|ccmitch|>    path accessors
    <brian_skinner>    okay
    <jared_j>    Fine by me, ccmitch
    <brian_skinner>    so then on to 2.2?
    <|ccmitch|>    also on save()
    <jared_j>    With regards to the drupal site, do we want to move everything on jot, or jettison some of it?
    <jared_j>    (Before we move on)
    <|ccmitch|>    for 2.3, i think this is a prob we should fix
    <brian_skinner>    jared_j: i don't know
    <|ccmitch|>    we'll want to start fresh for 0.9 i think
    <|ccmitch|>    or copy previous to archive notes or something
    <brian_skinner>    will the old jot site be kept alive for the record?
    <jared_j>    I would like to preserve the meetings at leasy, and yeah, archive the rest off as a history link or whatnot
    <|ccmitch|>    i think the plan is that it will eventually go away
    <brian_skinner>    i think there's some value in preserving the historical record -- it serves as prior art if some company tries to patent any similar technology in years to come, and then starts filing lawsuits
    <brian_skinner>    even for ideas that we ended up not implementing
    <|ccmitch|>    y, they can always archive the jot wiki before taking it offline
    <jared_j>    And it should be archived, yeah.
    <brian_skinner>    yup, but it's more useful if there's a copy on the web that people can search, even if it's just an html snapshot
    <brian_skinner>    anyway, these are problems for alex and dustin
    <jared_j>    Her's a quesiton on patents now that you bring it up: Is any company patenting items contributed ato dojond then donating the patents to dojo?
    <jared_j>    Donating to the dojo foundaiton, that is.
    <brian_skinner>    jared_j: not that i know of
    <jared_j>    I wonder if it's worth asking about to the companies contributing.
    <jared_j>    ccmitch: Any opinion?
    <|ccmitch|>    n, we can ask alex
    <|ccmitch|>    license gives copyright, but i dont think it grants patents
    <brian_skinner>    i think the CLA maybe does address patent rights
    <|ccmitch|>    guy, sorry, but i have to bail
    <brian_skinner>    okay, see ya |ccmitch|
    <jared_j>    I'll have to look over the CLA again
    <jared_j>    Seeya ccmitch.
    <|ccmitch|>    will keep irc on...
    <|ccmitch|>    ttyl
    <jared_j>    Anyway, back to on-topic things..
    <jared_j>    2.3: loadItem and async
    <brian_skinner>    skip 2.2 for now?
    <jared_j>    I would like ccmitch around for that one, he has opinions
    <jared_j>    on it
    <brian_skinner>    okay
    <brian_skinner>    2.3
    <jared_j>    I think you're right, we'll need to fix this somehow.
    <brian_skinner>    can we just make loadItem be async?
    <jared_j>    The simplest adjustment would be perhaps to just have it add callbacks to it (amke it async), of onComplete and onError
    <brian_skinner>    yup, that sounds good
    <jared_j>    To mimic is as sorta a subset of fetch (fetch *1* item)
    <jared_j>    No need for onItem, of course.
    <brian_skinner>    or we could just have onItem and onError, with no onComplete
    <brian_skinner>    if that seemed more intuitive
    <jared_j>    Sure, if you like
    <brian_skinner>    i've got no preference
    <jared_j>    I'm 50/50 on it too.
    <brian_skinner>    well, okay, maybe i do have a preference for onItem
    <jared_j>    onItem === shorter :)
    |<--    |ccmitch| has left irc.freenode.net ("KVIrc 3.2.0 'Realia'")
    <jared_j>    And it makes sense.
    <jared_j>    or does onLoad make more sense?
    <brian_skinner>    and with onItem, then the arg will match the fetch() onItem callback arg, right?
    <jared_j>    Well, no. You have no 'request' per se, do you?
    <jared_j>    (arg 2 of onItem)
    <brian_skinner>    right
    <jared_j>    so it would just be onItem(item), I guess.
    <brian_skinner>    yup, but that's at least close to the fetch() callback arg list
    <jared_j>    Question: Do we need abort support?
    <brian_skinner>    closer than onComplete
    <jared_j>    Agreed.
    <jared_j>    Go with onItem
    <brian_skinner>    abort -- i've got no idea
    <jared_j>    And oh, do we want a scope param? (I assume we do)
    <jared_j>    With return of one item, I'm hard pressed to see the need for abort
    <jared_j>    It in theory shouldn't be hugely time consuming.
    <brian_skinner>    could we make abort optional?
    <brian_skinner>    a datastore *may* return a request object that *may* define an abort function?
    <brian_skinner>    and then if the UI code wants to abort, it needs to check to see if an abort function was provided?
    <jared_j>    We could, yes.
    <brian_skinner>    or, we could simply not mention abort in the API spec, which amounts to the same thing as saying that it's optional
    <jared_j>    True.
    <brian_skinner>    whatever you think is best
    <jared_j>    We could leave it off for now. It's always easier to add later, as Alex says.
    <brian_skinner>    yup
    <jared_j>    I'll ask ccmitch's opinion tomorrow.
    <jared_j>    I prefer not to decide without a few viewpoints on it.
    <brian_skinner>    i don't know about scope either
    <jared_j>    fetch has scope
    <jared_j>    So I would think loadItem should too.
    <brian_skinner>    i guess i'd be inclined to say that loadItem should have a scope too
    <jared_j>    I agree,
    <brian_skinner>    and i guess that simple datastores won't even have to implement loadItem anyway, right?
    <jared_j>    loadItem is on Read. So yeah, they sorta have to implement it
    <jared_j>    But it's just a sync call at that point.
    <jared_j>    real simple.
    <brian_skinner>    but for CsvStore and JsonItemStore, all the items are pre-loaded
    <jared_j>    Right, so all it does is return/call the callbacks with the item asked ot be loaded.
    <jared_j>    No calls, file loads, etc.
    <brian_skinner>    hmmm...
    <jared_j>    If it's on the api, a store has to impl it.
    <jared_j>    It's just a dumb function on simple stores.
    <brian_skinner>    could we say that the loadItem implementation is only required to call the callbacks if isItemLoaded() has returned false?
    <jared_j>    We could say that, sure.
    <brian_skinner>    so that CsvStore and JsonItemStore can actually have a zero-line implementation of loadItem, and a single line implemenation of isItemLoaded
    <jared_j>    That would just mean users should call isItemLoaded() before even bothering.
    <brian_skinner>    which I think they should be doing anyway
    <jared_j>    Yeah.
    <jared_j>    That should be made explicit in the docs to just be sure, tho. :)
    <brian_skinner>    yup
    <jared_j>    So, what should the signature look like?
    <brian_skinner>    okay, does that resolve agenda item 2.3?
    <brian_skinner>    of loadItem() ?
    <jared_j>    loadItems(/*objject*/item, /*object?*/callbacks);
    <jared_j>    ?
    <brian_skinner>    hmm...
    <brian_skinner>    i don't know
    <jared_j>    loadItem(item, {onItem: foo, onError: bar, scope: bah});
    <brian_skinner>    that seems fine
    <brian_skinner>    or...
    <jared_j>    "Or does it make sense to put item into the anon objetc too?
    <brian_skinner>    loadItem({item: item, onItem: foo, onError: bar, scope: bah});
    <jared_j>    Fine by me
    <jared_j>    That's more consistent with fetch too
    <brian_skinner>    i can see arguments for either
    <brian_skinner>    i shouldn't even bring this up, but...
    <jared_j>    I'm of the opinion we choudl try to keep things consistent if possible
    <brian_skinner>    yup, consistent is good
    <brian_skinner>    do we want to allow for passing an array of items to loadItem(), or does that complicate things for no reason?
    <jared_j>    Hmmmmmmm.
    <brian_skinner>    sorry ;-)
    <jared_j>    Well, if we did that it should be loadItems(), not loadItem :)
    <brian_skinner>    right
    <jared_j>    We could always add that later if it seems needed. I'm not sure we really need it right now.
    <brian_skinner>    sounds good
    <brian_skinner>    YAGNIT
    <jared_j>    Define that? ;)
    <brian_skinner>    "You ain't going to need it"
    <jared_j>    Heh.
    <brian_skinner>    one of the eXtreme Programming mantras
    <brian_skinner>    http://c2.com/xp/YouArentGonnaNeedIt.html
    <brian_skinner>    actually, YAGNI, i guess
    <jared_j>    Sounds like the acronym YASQ I use a lot. Yet Another Side Question.
    <brian_skinner>    http://en.wikipedia.org/wiki/YAGNI
    <jared_j>    Anyway, back to data stuff...
    <jared_j>    Todo list would be good.
    <brian_skinner>    yup
    <jared_j>    I forget things periodically if I don't have it written down somewhere.
    <jared_j>    We can put that on the new drupal site maybe, or use the dojo trac capability if that's easier?
    <brian_skinner>    either way seems good to me
    <jared_j>    I think drupal is easyer than trac querying, but I may be in the minority., :)
    <brian_skinner>    yup, i would think a drupal page would be easier
    <jared_j>    If we decide something on the todo, we can always put it into track and just ref th enumber on drupal after the fact.
    <brian_skinner>    yup, sounds good to me
    <jared_j>    For todos we toss, no extra work.
    <jared_j>    todo ->todon't. :)
    <jared_j>    6 we've discussed.
    <brian_skinner>    have we run out of agenda items then?
    <brian_skinner>    is there other stuff that comes to mind?
    <jared_j>    dojox.wires we don't have a lot of time left for to discuss and you know about some of it already anyway. By thursday or so we should have a rough draft if a users guide for our prototype that will help for discussion on it
    <brian_skinner>    cool
    <jared_j>    Thinking
    <brian_skinner>    can you mail me a copy, or post it to the contributors list?
    <jared_j>    I hope post it to contrib
    <jared_j>    I'll have to et quick approval on that.
    <jared_j>    I don't think there wil be an issue, but I have to check. Legal scares me...
    <brian_skinner>    yup, better safe than sorry
    <jared_j>    As for save name change, I liked commit and rollback
    <jared_j>    Personally.
    <jared_j>    But I'd like to hear ttrenka, Alex, Peller, and such opinions
    <brian_skinner>    do you know what chris prefers?
    <brian_skinner>    commit? flush?
    <jared_j>    Not offhand, but I can find that out pretty quickly tomorrow morning.
    <jared_j>    commit makes more sense to me than flush
    <brian_skinner>    i don't like flush, but either save or commit seems reasonable to me
    <jared_j>    flush doesn't make sense to me in terms of what you are doing
    <brian_skinner>    it would be good to hear from alex, peller, ttrenka
    <jared_j>    Right
    <jared_j>    Well, 5 min before 6 EST. Anything else or want to close out here?
    <brian_skinner>    do you attend the wednesday dojo meetings -- if so maybe you could raise it as a quick one-minute question there
    <jared_j>    I do attend those when I can, yeah
    <jared_j>    I'll try to remember to do that tomorrow.
    <brian_skinner>    if it wouldn't be too off-topic
    <brian_skinner>    easier to catch more people there
    <brian_skinner>    ...
    <jared_j>    If we have a dojo.data update request I can ask there
    <jared_j>    SOmetimes Alex asks for updates
    <brian_skinner>    ...
    <brian_skinner>    i don't have anything else for today
    <jared_j>    I don't either.
    <brian_skinner>    thanks for doing all this work
    <brian_skinner>    it's been wonderful to see so much rapid progress on dojo.data
    <jared_j>    Np. I just wish it was going faster. :)
    <brian_skinner>    :-)
    <brian_skinner>    well, it's going a lot faster than it was before you got here!