Log file opened at: 2/8/01 7:04:14 PM #addressbook: peterv_logger rsr411 ch88 James peterv srilatha leif dmoseAwy dmose cuchulainn *** End of /NAMES list. *** Mode is + *** Channel created at Monday, February 5, 2001 7:05:32 PM *** jm84909 (jm84909@beryllium.eu.sun.com) has joined channel #addressbook dmose: other folks, care to introduce yourselves? jm84909: John Marmion here from Dublin ... James: I'm James, responsible for the addressbook project in Sun peterv: i'm Peter Van der Beken, working for Netscape on XSLT peterv: hacked a bit on LDAP rsr411: I'm Dick Rhoads, mostly an interested LDAP user *** bursi (bursi@beryllium.eu.sun.com) has joined channel #addressbook cuchulainn: Martin Maher working with John Marmion in Sun Ireland *** Signoff: bursi ([x]chat) *** BenB (ben@pD901451C.dip.t-dialin.net) has joined channel #addressbook BenB: hi dmose: howdy *** BenB has set the topic on channel #addressbook to LDAP meeting dmose: ok, so I wrote most of the XPCOM LDAP wrapper that's currently in the Mozilla tree dmose: and I've just moved over to join Leif and Srilatha in Netscape's eClient team James: Dan, I understand you know what we are trying todo from Paul Sandoz BenB is Ben Bucksch, founder of Beonex, loser rtg LDAP support ch88: Can you explain a little on what's your approach? My understanding on LDAP for address book is from using 4.x. In 4.x , we search on ldap server and save it into database that;s it. It looks like you are going to do more than that. BenB: eClient? dmose: James: yes, in fact yesterday I posted the HTML files from your PDF on mozilla.org dmose: the link can be found from http://www.mozilla.org/directory/ dmose: under "addressbook refactoring proposal" dmose: so our (Netscape's) goals overlap a fair bit with the Sun Ireland goals *** bursi (csaba@beryllium.eu.sun.com) has joined channel #addressbook dmose: but our theory is that we are looking for typedown address completion to land in mozilla for the 0.9 timeframe dmose: (mid march) dmose: whereas the issues that the Sun folks are working on are very interesting to us too, but in a slightly longer term than that. James: Is typedown the same as autocompletion dmose: so there's a couple of issues to bring up here, I think. dmose: James: yes dmose: the first issue is probably to hear any feedback on the addressbook refactoring proposal James: We have refactored code so that we have access to locall AB and quesry access to LDAP James: We have had no feedback as far as I know dmose: candace, did you get a chance to look at that paper (it's the same info as the link mentioned above) dmose: ? ch88: I'm s slow typer. wait.. James: We would expect to have working code by the end of the month dmose: I've looked at the paper myself, and on the surface it seems reasonable, but I'm just a beginner in the addressbook code, so I can't provide a lot of better feedback than that) James: Our main question is how we might integrate this *** David (david@129.59.47.205) has joined channel #addressbook dmose: it certainly seems like the only way to get to a more generic addressbook structure is to factor the mork database stuff out of the addressbook cuchulainn: well not out more to the side.. dmose: into different interfaces, that is James: yes cuchulainn: yeah that's it ch88: I did see it. I think it's ok to restructure. I need to know how are you getting the data from and how are you going to store it? directly from the server, rdf or local. cuchulainn: at the moment it's local James: through Dan's LDAP XPCOM component leif: Before we go too deep, do we have two "issues", or just one? I mean, is typedown/address completion going to stay separate from Addressbook, or are they closely tide together? dmose: leif: that's the second thing on my agenda. dmose: leif: i'd like to get this sorted out first, though, as i think it's a larger issue and will have some bearing on our thoughts about the typedown James: Martin - I thoough only the prefs were stored locally dmose: so James, cuchulainn: the theory then, will be to have multiple addressbooks, some of which get their data from reading mork databases, and others of which get their data by talking to (eg) LDAP servers. true? cuchulainn: dmose: yes ch88: Would it be slow if you doing the typedown by talk ingto LDAP directly? leif: ch88: Isn't that how Comm 4.x does it? dmose: ch88: well, it'll be a lot slower than local disk. but i'd be surprised if the slowdown were actually perceptible by the user. bursi: leif: yes, the Comm 4.x does that jm84909: we have not investigated autocompletion + ldap James: we think we will need to differentiate between corporate and personal ABs dmose: James: I liked that part of the proposal a lot. James: in corporate, the autocompletion will have to happen on the server side ch88: People already compain the address book is slow, we need to think about it. dmose: James: in fact, it sounded like you guys were more interested in focussing on the personal addressbooks. James: on personal, we could filter on the client side dmose: James: which is cool, because I think netscape management is more interested in 4.x style addressbooks (ie corporate) leif: James: Would a "personal" user even use LDAP? dmose: leif: this is the star webtop thing, i believe. dmose: right? James: yes leif: ah dmose: ch88: true. has any profiling been done on the addressbook code to see where it's bottlenecks are? BenB: dmose: I do know that mork is not very scalebale. I think, bienvenu said that. ch88: I guess most is from a bug address and we don't have a good way for query in mork. dmose: bug address? BenB: dmose: up to 1000 or a few thousand, perf is reasonable, declining lineary, IIRC. There is a post about that on .mail-news, dated a few months back ch88: dmore: a big address book dmose: James et al: so the plan is not to use mork for the address book, right? leif: so when would the Mork bottleneck come into place, when replicating (off-line) data from an outside source (LDAP)? dmose: s/address book/ LDAP entriess/ BenB: leif: yes. cuchulainn: whoa there cuchulainn: mork stays all we are doping is adding extra datasources dmose: right; i typo'ed dmose: that's what the s/// fixup was James: dan : one can use mork alongside ldap leif: Well, we do need to support off-line LDAP support, which can mean 100K entries into Mork, or more... dmose: what i was really asking was a version of leif's question: the mork slowness shouldn't affect the more abstracted addressbook layer if just using LDAP James: no dmose: BenB, Candace: so what is the prognosis for Mork in mail-news? is it here to stay? ch88: I don't get it , do you mean mork will go away. dmose: s/Candace/Candice/ sorry! BenB: dmose: i don't know for sure, but i think so. iirc, it was rewritten for Mozilla. dmose: right dmose: well, it was written for mozilla dmose: but if it's causing bottlenecks in parts of the code, i'm curious as to whether it will stay BenB: dmose: IIRc, there is room for improvement in perf dmose: as i've heard occasional speculation that we could do better than mork BenB: dmose: well, XUL is slow, too :) leif: lets rewrite XUL then :) cuchulainn: I think we're getting off the point mork is here for the immediate future BenB: leif: no, throw it away! ;-P jm84909: Well if mork goes away at some point -then refactoring will aid this dmose: cuchulainn: yes. dmose: jm84909: excellent point. ch88: I haven't heard anything about getting rid of mork inside our team though. dmose: ok, so i know that local disk caching of LDAP addressbooks isn't terribly high on our priority list just yet. leif: yes, that is a very good point, refactoring should make it very easy to replace Mork once it's performance limitation becomes critical for new features. dmose: so maybe we can cross that bridge when we get to it jm84909: our main concern would be to keep existing functionality but add LDAP access dmose: ch88: thanks; that's what wanted to know. cuchulainn: candice/dmose what is the process for trying to get code back into mozilla dmose: submit it as a patch, get it reviewed, get module owner-approval, ge super-review checkin ch88: My manager is concerning this should not affect our beta. cuchulainn: when is the beta dmose: so in this case, candice is the module owner BenB: cuchulainn: fiist, file a bug. cuchulainn: BenB: there already is one BenB: cuchulainn: see www.mozilla.orghttp://www.mozilla.org/hacking/ James: should we have specific functionality dmose: ok, i'm gonna zoom forward to our second issue for a moment, as that seems relevant.... James: or problem is the longer we write code the more problems we have merging dmose: because we eclient folks are interested in typedown addressing for 0.9 dmose: our theory is that it'll probably be too hard to do the elegant/right thing and wait to integration with any addressbook refactoring BenB: cuchulainn: mozilla 0.9 == beta for ns6.5, I think. bursi: dmose: before that. Do you have reference platform to build? dmose: so my current best guess is that we'll do typedown-addressing directly between LDAP/XPCOM and autocomplete, with no addressbook layer in between dmose: and perhaps migrate to the addressbook layer in the future if that seems feasible dmose: bursi: mac, linux, win32. the URL that BenB pasted above should have most of the relevant info. leif: dmose: One thing though, shouldn't we try to make the UI to configure the LDAP server(s) be the same for Addressbook and typedown? James: then our work should not initially clash BenB: James: yes, get the stuff into cvs dmose: James: right, except for what Leif said dmose: ducarroz said he'd try and show up here in about an hour, and i'm gonna talk to him more then about how feasible this current thinking on typedown is jm84909: dmose: will you add auto-c to the existing LDAP/XPCOM wrapper dmose: autoconfig? dmose: er autoconf? jm84909: autocompletion dmose: probably not exactly dmose: i need to talk to ducarroz about this... James: will you filter the result set in Mozilla dmose: but my current guess is that we'll write code that lives in or near nsAbAutoCompleteSession peterv: does it currently use RDF? dmose: typedown does not currently use RDF, no peterv: hmm dmose: the addressbook does though dmose: and that code that lives in or near nsAbAutoComplete session will call into the LDAP XPCOM wrapper to do the work dmose: James: how do you mean "filter"? James: if the XPCOM/LDAP wrapper does autocompletion, then we could use it *** putterman (scottip@208.12.40.143) has joined channel #addressbook dmose: scott! putterman: hey James: i am not clear where the results are being accepted/doiscarded against the typedown dmose: James: so the text entry widget in the To: and Cc: lines of the compose window have an autocomplete XBL handler bound to the, dmose: s/the,/them/ dmose: that handler gets called with the current prefix, and gets asked to return a set of matches dmose: which are then put directly into the menu, i believe dmose: does that answer your question? cuchulainn: leif: when do plan to add support for adding/editing cards to LDAP bursi: dmose: Correct me, if I'm wrong: The autocomletion is "just" a front and issue. Tha LDAP XPCOM wrapper doesn't have to prepare for that. dmose: bursi: correct dmose: bursi: which is why i don't entirely understand James comment "if the XPCOM/LDAP wrapper does autocompletion, then we could use it" leif: I'm not sure what the plans are for all LDAP related features. I know we need typdown for the march beta, which is the #1 priority cuchulainn: so it will be after that? dmose: bursi: it's unlikely that we'll be doing any writing/modification code for the LDAP XPCOM wrapper James: okay but does this scale on a corporate ldap server to return all cards to the frontend leif: Probably, depends how we're doing on time (but my guts feeling is that just getting typedown in there is going to be more than enough to keep us busy) dmose: bursi: but we're accepting patces. :-) leif: What I'd like us to do thoug is getting the UI around LDAP configurations "unified", so that it doesn't have to change once we add more LDAP related features, that would just confuse the users. bursi: dmose: OK. dmose: James: so we were talking about that the other day. and one theory we came up with is to ask the server how many matches it would return for a given search... dmose: James: and if it's more than can conveniently fit in a menu, simply refuse to autocomplete dmose: and wait for further typedown James: leif : have you done work on this leif: Unfortunately you can't ask for the number of entries to be returned when doing async LDAP. dmose: leif: agreed; that would be a fine thing dmose: leif: but didn't we decide we could do this indirectly? leif: What you can do is set a size limit on the search, and if the search results in more than that limit, an error is returned bursi: dmose: The number of the matches would be a preference or configure setting. dmose: leif: by asking for a maximum return set size of 20 or something and seeing if it errors out? dmose: bursi: sure; that makes sense BenB: dmose: will servers be happy, if you ask them "how many entires do you have for "a*""? leif: No, searches like a* is *VERY* bad, autocompletion should never be attempted on that... :( peterv: so how does 4.x handle that? synchronously? BenB: leif: you already answere my question before... dmose: so we'll have to code in some other constraints about when to simply not autocomplete dmose: that shouldn't be difficult James: i though autocompletion required a return key press leif: At a minimum, two characters should be required, because the way iPlanet LDAP servers handle searches, something like a* will always be an unindexed search, and it has to walk through the entire database. dmose: James: i think srilatha has been doing some thinking on prefs front, maybe she has input there. bursi: James: in Netscape not. *** ducarroz (ducarroz@208.12.41.190) has joined channel #addressbook James: i see it in netscape 4.75 dmose: ducarroz! peterv: James: right bursi: James, dmose: Sometimes it is annoying, when you stop with typing and Netscape starts to search. Of course, you can switch off the autocompl. srilatha: James: then we will have the same in 6.5 ducarroz: Hi, I am here just for few minutes... dmose: duccaroz: ok, lemme catch you up on the relevant issues via /msg BenB: leif: well, my personal little LDAP server will prbably be fine with a*, and I may want that. leif: BenB: The sizelimit on the search wouldn't prevent an LDAP server to be unhappy with a search like a*, it'd still have to walk the entire database... We see this all the time on our local LDAP servers... :( BenB: leif: oh, ok. bursi: dmose: I suugest to have a cancel operation for autocompletion. But this is already low level issue, isn't it? leif: A cancel feature would be awesome, particularly if an LDAP server is unreachable (for whatever reason). In Comm 4.x the userhas to wait for the TCP timeout before getting back an error... :( dmose: bursi: that's a good idea ducarroz: autocomplete already fire a cancel operation when the user press a key. leif: Cool! ducarroz: but cancel will really work with an async search engin which it can support already bursi: dmose: ie. yesterday I could not reach an LDAP server, and my Netscape was freezed for 3-4 minutes during the autocompletion dmose: ducarroz: can you elaborate on that last sentence? dmose: bursi: yeah, that's bad leif: LDAP is async (if you use the async API, which I believe the XPCOM wrapper uses exclusively) dmose: it does ducarroz: the current search engin for autocompletion is synchronus, therefore once the search initiated, you cannot stop it. leif: The C-SDK API should also have functions to cancel an outstanding request. ducarroz: but the way I have designed tha autocomplete widget, you can plug an asynchronus search engin leif: alrighty, thank you! ducarroz: the LDAP search engin must be async. bursi: ducarroz: That's why I suggested the cancel function as you type further. dmose: ducarroz: the search engine? you mean the implementor of nsIAutoCompleteSession? leif: are we going to stay "compatible" with Comm 4.x when it comes to autocompletion and it's behaviour? Like search personal abook first, and then any selected LDAP server if needed? ducarroz: right bursi: ducarroz: in a level of LDAP access, it is async. At least I hope, that the LDAP wrapper use that type of query. dmose: bursi: it does dmose: ducarroz: ok, that shouldn't be a problem bursi: dmose: fine! dmose: leif: i like idea of making it slightly more configurable.... like mail-filters ducarroz: Yes, we should try to be as must as possible compatible with 4.x dmose: leif: have a list where you can change the order of precedence BenB: leif: what dmose says makes sense. dmose: leif: but the scenario you described would be the default sort order leif: One thing I'd like to see is the possibility of searching more than one configured LDAP server (or maybe same server, but multiple base-DNs for multiple searches) BenB: leif: e.g. autocollect - I may keep my address book on the serverm, but use autocollect, which is local. i want the server entiries to have precedence dmose: leif: the UI I just described should be able to do that nicely, i think dmose: ducarroz: is it possible to bind multiple autocomplete handlers to a single text field? leif: dmose: Yeah, maybe a list UI of all addressbook data sources, where you can arrange order, check box if it should be used, and maybe a checkbox if searches should stop after finding one single entry matching (and so on) ducarroz: no ducarroz: sorry, gotta go, I'll be back in about 30 minutes... dmose: ducarroz: so either I need to hack nsAbAutoCompleteSession or construct a "composite autocomplete sesssion"? dmose: leif: exactly rsr411: leif: yes, exactly like that ch88: Head for another meeting, be abck dmose: wow; time flies when you're having fun dmose: didn't realize it was already 11 bursi: dmose: one more : Do we have to care about any internationalisation issue? leif: dmose: It sounds like we need to come up with a new autocomplete session, which can handle the multiple searches/sources. dmose: bursi: yes dmose: bursi: I don't exactly know what, though. bursi: dmose: where can we get info about it? BenB: dmose: lol dmose: bursi: i'd start by asking candice when she returns dmose: leif: right, that's what i meant by "composite" autocomplete session, analogous to the way RDF datasources can be composited BenB: at least, the entires (names) can be unicode leif: It gets particulaly narly with LDAP, because you can have tagged attributes like CN;en=Leif hedstrom CN;sv= BenB: (obviously) dmose: LDAP itself speaks UTF-8 dmose: so i suspect this isn't terribly difficult, we just have to wedge the right converters in the right places. dmose: dunno about non-Roman alphabets, bidi, etc. leif: Yes, but LDAP also allows you to have multiple values for CN, and you have to pick the "right" one depending on langugate prference. dmose: oh, that's interesting leif: (or most values) dmose: leif: do man people use that feature? dmose: s/man/many/ leif: Probably not in the US... bursi: dmose: And one more: What LDAP card sheme do we want to support? (inetOrgPerson?) dmose: bursi: this seems like it makes the most sense, since it's what most folks use in their LDAP servers today, I believe leif: But, I can see it being used more widely in Asia, where you want to have one represantion using regular characters and one using the native symbols bursi: dmose: I think too. dmose: and since the existing addressbook code in Mozilla uses something that's almost exactly that format bursi: dmose: OK, that is fine. dmose: leif: so we might have to hook into the prefs to find out the preferred language. leif: Maybe dmose: leif: i suspect that won't be too hard. leif: There are a few entries in the Netscape LDAP server that uses this feature I think. jm84909: See you guys - I am away - thanks for all the responses dmose: so as far as getting the Sun addressbook refactoring into the tree, probably the first step.. dmose: is to talk to candice more, and send her your code. dmose: probably the most interesting thing will be what the refactoring might break that uses the existing interfaces dmose: eg the AddressBook Sync stuff James: that sounds good. thanks. dmose: sure thing *** Signoff: jm84909 ([x]chat) James: who is writes the sync stuff James: s/is/ dmose: i'm not sure; try poking around with lxr and cvsblame cuchulainn: dmose: we needed to cover a lot of stufff with candice about putbacks dmose: candice would know, i'm sure cuchulainn: and with others about what possible might break the build cuchulainn: it's not looking like we'll get to do this tonight dmose: cuchulainn: understand. well maybe a good forum for this would be .mail-news, as most of the folks who care about the addressbook book hang out there BenB: dmose: can't use the navigator language preference? or is that overload (i.e. might a user want to have different values)? dmose: cuchulainn: no, i think another meeting or two could be useful leif: cuchulainn: Is your code ready? BenB: dmose: maybe just compibe the UI= BenB: combine dmose: BenB: that's what i meant, actually, using the navigator preference. but i haven't given it much thought. dmose: some time soon I'll try and get one or two of the i18n folks to come lend some expertise. cuchulainn: not yet but will be by the end of Feb bursi: I gotta go too. See you and thanks for contribution. leif: Ok, so it's fair to say that for Mozilla 0.9, we can't rely on addressbook being refactored. BenB: rhp wrote absync, but he is gone. cuchulainn: what date is 0.9 *** Signoff: bursi ([x]chat) leif: March 13 or something like that? cuchulainn: well then it has a chance srilatha: 3/14 dmose: BenB: but didn't some other guy (Tony something?) write a bunch of the absync converters? dmose: leif: if you mean we == eClient relying it on for typedown work being done by then, i believe that's correct. BenB: dmose: i know about rhp only. leif: well, also, remember, if there is a chance to get LDAP support in the Addressbook for 3/13, JPM would be very happy... :) James: i've got to go. thanks for your time. dmose: absolutely, this would be a fine thing dmose: ok, thanks for joining us everyone BenB: dmose: this is state of a few months ago, duuno if something new came in since then peterv: dmose: any idea if the datasource would help for the addressbook? dmose: peterv: i believe so, yes. cuchulainn and the other sun guys probably have more expertise there than i do. peterv: hmm, i might be tempted to work on it further. But i'd need to know what's important first. Log file closed at: 2/8/01 8:25:26 PM