[09:11:03] --- arnt has joined
[09:57:15] --- alexeymelnikov has joined
[09:59:07] --- cyrus_daboo has joined
[10:02:42] --- Dave Cridland has joined
[10:03:10] <Dave Cridland> Afternoon/Evening/Morning
[10:03:16] --- cromwellian has joined
[10:03:37] --- eburger has joined
[10:03:51] <arnt> hi
[10:04:08] <eburger> Good morning everyone.
[10:04:13] <eburger> (or afternoon for Arnt)
[10:04:20] <Dave Cridland> (and me/Alexey)
[10:04:28] <eburger> Right -- I see you now.
[10:04:36] <eburger> The phone lines are open, if you want to add voice.
[10:04:48] <eburger> (I'm the virtual Glenn)
[10:05:06] <alexeymelnikov> Dave/myself - we are not listening to audio
[10:05:07] <cromwellian> alexy u here
[10:05:07] <eburger> Is Dave Cridland around?
[10:05:14] <Dave Cridland> I think I am.
[10:05:15] <alexeymelnikov> (i.e. we are only in jabber)
[10:05:16] <cromwellian> i see him online
[10:05:45] <eburger> OK. We've got Dave, we've got Ray, I think we have a vfolder / contexts quorum :-)
[10:06:03] <cromwellian> im not on voice yet until the baby wakes up which should be soon :)
[10:06:24] <cromwellian> i tend ot talk too loud when discussion gets contentious
[10:07:10] <cromwellian> ive been a bad boy, I haven't turned in my updated convert draft yet sorry, will get it out today
[10:07:24] <eburger> Randy, Curtis King, Dan Karp all said they will be on, but I don't see anything
[10:07:57] <cyrus_daboo> There was a lot of too and fro about the time _ I wasn't totally sure it was still on Monday.
[10:08:01] <alexeymelnikov> Curtis is busy, even though he is just 10 meters from me
[10:08:16] <eburger> Shall we get started anyway?
[10:08:20] <arnt> let's start
[10:08:27] <alexeymelnikov> Sure
[10:08:40] <arnt> I have to leave in 90 minutes or so, a little earlier if possible, so waiting an hour to start is... suboptimal
[10:08:42] <cromwellian> can everyone see what im typing?
[10:08:50] <eburger> Ray - yes.
[10:08:52] <arnt> pity for ray and whoever else is on the west coast
[10:08:56] <Dave Cridland> Ray - Yup.
[10:09:21] <cromwellian> i've had worse, those 4am W3C WG meetings were killers
[10:09:21] <eburger> So, what can we agree on; what do we need to agree on, and what do we need to discuss for vfolder / context?
[10:09:58] <arnt> I'd like to discuss what we're trying to achieve.
[10:10:07] <cromwellian> eric, I think the slides I presented on this may be somewhat helpful
[10:10:18] <arnt> there's an OMA requirement. what's it's wording? are there other requirements?
[10:10:33] <Dave Cridland> cromwellian: You have a URL for those?
[10:11:17] <eburger> Slides from IETF are at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[10:11:31] <eburger> What about OMA stuff?
[10:11:59] <eburger> Or, if someone can cut-and-paste the OMA stuff, that would work, too
[10:12:11] <cromwellian> starting here: http://www3.ietf.org/proceedings/06nov/slides/lemonade-3/sld5.htm
[10:12:33] <cromwellian> this one in particular: http://www3.ietf.org/proceedings/06nov/slides/lemonade-3/sld7.htm
[10:12:52] <eburger> Any comments?
[10:13:11] <eburger> (Chair hat off) last bullet on slide 5 doesn't really mean anything
[10:13:40] <Dave Cridland> Given that IAB hasn't really got a set of goals here?
[10:13:46] <eburger> (channeling for Greg V.) Some folks are hoping that the notification protocol could carry entire message.
[10:14:11] <arnt> I'll send Greg a .iso file if he says that again.
[10:14:12] <eburger> (channeling for me) I think the point of notification protocol, and not POP, is to not have the entire message in the payload.
[10:14:42] <alexeymelnikov> Are we talking about notifications in general today?
[10:14:47] <eburger> Any comments on slides 5 &7? Great ideas? So stupid you can't begin to type?
[10:14:51] <cromwellian> the gist of the ietf67 presentation is to make context/vfolder more integration, e.g. share the same filter naming mechanism, etc
[10:15:15] <eburger> Thank you Alexey for pulling me back into today's topic
[10:15:22] <Dave Cridland> Alexey's filter naming allows that to happen in a neatly orthogonal manner.
[10:15:28] <eburger> Today is supposed to be about vfolder / contexts
[10:15:55] <alexeymelnikov> I.e. out-of-band is out-of-scope today :-)
[10:16:06] <eburger> That would be Ray's slide 4
[10:16:40] <cromwellian> Dave, what did you think of my idea to make vfolder dependant on context, e.g. the way you create vfolders is to first create a named context, and then bind it to a folder/named view?
[10:16:46] <Dave Cridland> To give my take, I think virtual folders basically work well where the criteria are not dynamic, and contexts basically work well when they are.
[10:16:56] <eburger> Also see http://www3.ietf.org/proceedings/06nov/slides/lemonade-1/sld6.htm and following
[10:17:27] <Dave Cridland> Ray: I think that's effectively addressed by Alexey's draft - ie, you'd define a named search criteria "macro", then use it for vfolder/contexts.
[10:17:42] <eburger> And http://www3.ietf.org/proceedings/06nov/slides/lemonade-4.pdf
[10:18:11] <Dave Cridland> Ray: I don't think it helps WRT the biggest problems with vfolders, which are basically messages vanishing and reappearing, and UID reallocations causing message redownloads.
[10:18:25] <cromwellian> perhaps then we should discuss the dyanmic vfolder issues since Arnt is here, and he has implemented them
[10:18:39] <arnt> ray, hasn't oracle too implemented them?
[10:19:20] <Dave Cridland> FWIW, my context slides are also at http://dave.cridland.net/slides/ in various formats.
[10:19:45] <cromwellian> well, oracle has, since the p-imap days and XPSEARCH, but since Oracle's IMAP server is backed by an Oracle RDBMS, they don't get scared by keeping an extra index per vfolder :)
[10:19:50] <arnt> I believe I sent mail about the reappearing stuff: people haven't complained about reappearance in one vfolder, but complain loudly about downloading both in a vfolder and in the backing mailbox.
[10:20:21] <arnt> ray: want to see my postgresql schema? ;)
[10:20:34] <cyrus_daboo> Right - duplicate download is the biggest pain given that we are supposed to be minimizing downloads etc for mobile devices.
[10:20:44] <arnt> there's a catch.
[10:21:23] <cyrus_daboo> That's why I think VFOLDERs have to be treated as "special" mailboxes wtih emantics different than regular mailboxes. Those new semantics would take care of duplicates and alleviate re-appear problems etc.
[10:21:24] <arnt> people don't complain about the download very much, but about the display on-screen. ie. about having to look at the mail twice.
[10:22:19] <Dave Cridland> Cyrus: But if you're doing that, I think you're immediately erasing one of the nice advantages of vfolders anyway.
[10:22:20] <arnt> that's why I suggested being able to define a search key to match that which no other vfolder matches. the mail should be dated june or so.
[10:22:23] <cromwellian> the most likely case where messages would reappear would be basing vfolders on flagged/unseen right?
[10:23:03] <Dave Cridland> Ray: Yes. But as I've said before, both those are view filters I use a lot, personally.
[10:23:09] <arnt> ray: yes, flag-based searches do that sometimes. not so much unseen, but flagged can do it often.
[10:23:16] <cyrus_daboo> For re-appear - "more than one week old" where the original mailbox was not proeprly sorted by date etc
[10:23:58] <cyrus_daboo> NB Its not re-appear per se that is the problem, but rather insertions into the mailbox that are not at the end.
[10:24:28] <Dave Cridland> Cyrus: True, in as much as the only way to reinsert is to reappend.
[10:25:43] <cyrus_daboo> Which assumes you require the current IMAP UID semantics - but that could change.
[10:25:51] <arnt> cyrus_daboo: what you want is context. fine new semantics.
[10:25:55] --- Glenn Parsons has joined
[10:26:47] <cromwellian> can we really loosen the semantics? don't clients depend on those for synchronization logic?
[10:26:51] <Dave Cridland> arnt: Exactly - CONTEXT defines semantics built on SEARCH/SORT.
[10:27:22] <cyrus_daboo> Yes _ I am leaning more towards context than vfolder. Particularly if you allow them to be named - i.e. multiple contexts per client connection.
[10:27:27] <arnt> we can loosen the semantics IFF we drop hope of compatibility with existing clients. that's not very attractive to me. I want outlook on the desk to see the vfolder.
[10:27:37] <Dave Cridland> Ray: Yes, although in principle we could define VFOLDER semantics which differed from normal-mailbox semantics, but I suspect there's a large can of worms there.
[10:28:19] <cromwellian> I guess you could do something like "SELECT vfolder" "OK [RELAXEDSEMANTICS]", but then it kills legacy client compatibility
[10:28:29] <Dave Cridland> Arnt: Yes, me too - which is a potential argument for having both VFOLDER - for "static" searches - and CONTEXT - for dynamic view filters.
[10:29:50] <arnt> foot irons so outlook can't do anything very useful? while I might agree that outlook's authors deserve a little something, that seems over the top.
[10:30:05] <cromwellian> I still think there is alot of use of vfolders if used on immutable properties, but I can see the use case for using it on flagged/unseen/deleted, but CONTEXT could be used for those
[10:31:00] <cromwellian> but I am biased to the way I use mail. I don't use flags that much, instead, I search on headers to create views (e.g. contains '[lemonade-wg]'
[10:31:22] <arnt> ray: do you use OLDER/YOUNGER?
[10:31:39] --- randy has joined
[10:31:48] <cromwellian> if the future moves away from folders and towards "tagging", that might change the usefulness of an immutable-only vfolder
[10:32:26] <cyrus_daboo> Many desktop clients already handle VFOLDERs via local virtual folders. They have the bandwidth to download everything and do that. If you add server-side VFOLDERs all you will do is have two ways to achieve the same thing on those and that will confuse users. A better choice is to agree on a way to specify the criteria users want for their virtual folder views and communicate that to all clients. Desktop clients can then use that to implement local virtual folders, and others can use context.
[10:32:30] <Dave Cridland> Ray: Tagging seems to have hit everything else. Admittedly, it's less than a decade since "keywording" was considered a waste of time that nobody used.
[10:32:39] <alexeymelnikov> As a user I am somewhat tempted to use OLDER/YOUNGER
[10:33:14] <arnt> cyrus_daboo: you don't see a problem in the two independent, but hopefully matching definitions?
[10:33:39] <cyrus_daboo> Arnt: where are there two definitions?
[10:34:29] <eburger> I'm not tempted to do YOUNGER: except for start-up, the messages will already be on my device, so all YOUNGER does is have me purge stuff
[10:34:46] <arnt> thunderbird's view is defined locally in its configuration. PDA's view (intendedly the same thing) is defined somewhere thinderbird doesn't look.
[10:34:52] <cromwellian> maybe we need the concept of "softlinks" in IMAP :) Then messages can exist in multiple folders via reference, and the client would not have ot download multiple times. Duplicate UID would just force append of a reference to the box, an empty IMAP message that contains only a reference to the original msg :)
[10:36:13] <arnt> (there's perfect silence on the phone. shall we hang up?)
[10:36:35] <cyrus_daboo> Arnt: my proposal is to standardize on a place where all clients can look for a users required virtual folders. Yes - that means having to change desktop clients to adopt this, but it will ultimately lead to better interop, and less need for users to configure each client each time.
[10:36:45] <Dave Cridland> Ray: Again, you're essentially creating new semantics.
[10:36:53] <eburger> LAST CALL FOR VOICE BRIDGE...
[10:38:18] <eburger> Maybe we need new semantics to make vfolder / contexts work?
[10:38:19] <arnt> (ah, that's better. the phone's loudspeaker was making static.)
[10:38:37] <cyrus_daboo> Ray- given the propensity of a lot of people to just leave everything in their INBOX and do virtual view of that one (c.f. GMail approach) I think we will need to add a mailstore wide virtual folder extension at some point - but I think we need to get the per-mailbox one right first.
[10:39:04] <cromwellian> the redownload issue seems to exist regardless of the duplicate UID issue. If we only allow immutable vfolder search (no dynamic attribtues), a client can still see the same message in 3 different folders, and thus will have 3 different copies
[10:39:13] <alexeymelnikov> Cyrus: Multimailbox search + CONTEXT would do the trick
[10:39:30] <arnt> ray: and the user will still complain about reading the message three times.
[10:41:19] <cyrus_daboo> Ray - if we add an OUID (original UID) property to FETCH and a way for a client to know it is dealing with a VFOLDER, then those clients aware of that can avoid the re-download problem. Again requires existing clients to be updated.
[10:42:11] <randy> There was a proposal for a mailbox ID, so FETCH could return Mailbox ID, UIDValidity, and UID of actual message
[10:42:29] <randy> Sorry, can't recall who suggested it. Dave, perhaps?
[10:43:01] <arnt> it may have been I, but I'm don't strongly favour it. I put it forward just so we'd have something concrete to discuss. there was a too-fuzzy thread.
[10:43:06] <cromwellian> i don't know if requiring update of existing clients is a dealbreaker, since non-upgraded clients 'degrade gracefully' (well, awkwardly atleast. they still work, but are inefficient and annoying if the user exercises vfolders too much)
[10:43:08] <cyrus_daboo> There is no need for Mailbox ID/UIDVALIDITY in every FETCH as the backing mailbox is always a constant for any VFOLDER.
[10:43:46] <randy> For multi-mailbox vfolder/context it would be needed
[10:43:48] --- Dave Cridland has left: Replaced by new connection
[10:43:52] --- Dave Cridland has joined
[10:43:55] <cyrus_daboo> The best way to get clients upgraded is to have users complain to vendors that they are lacking a key feature other people have - competition is good!
[10:45:01] <randy> Cyrus's suggestion of a standard criteria, storage location, and name for such things that could be implemented locally by desktop clients and on the server for mobile clients is interesting.
[10:45:03] <Dave Cridland> Cyrus: What vendors? MUAs are pretty much always free, and users tend to argue from the UI perspective.
[10:45:26] <cromwellian> I think multimailbox is an extremely important feature. I must admit, in the past, I used ot be somewhat nonplussed by it, given my clients typically could search every folder anyway, but those were desktops, and issuing a dozen searches on wired connection is no big deal
[10:45:34] <cyrus_daboo> Randy - yes you need to know what the backing mailbox is and its UIDVALIDITY, but you only need that one when you do the SELECT of the VFOLDER. After that you assume it does not change in that session - if it does, then the server has to return NO's or punt the client off that connection.
[10:46:33] <cromwellian> Dave, I think cyrus is saying that if Client A doesn't know about OID and gets duplicate downloads, and Client B is aware of OUID extension and avoids duplicate downloads, user of Client A will either demand features that Client B has, or buy Client B product
[10:46:37] <cyrus_daboo> Dave MUAs may be free but they are not all open source. Outlook/Notes are the two big ones for desktop, but many clients burnt into mobile rom's are closed.
[10:47:36] <Dave Cridland> cromwellian: My point being that in general, the users are more likely to complain about seeing the message twice, rather than observing that the mobile bill is higher.
[10:48:19] <randy> Cyrus -- if the vmailbox/context works across multiple mailboxes, then a client will need to know in which mailbox a message lives if it wants to be sure it doesn't download it more than once.
[10:48:29] <cromwellian> true, but in regard to lemonade clients on mobile, pretty much all will be new implementations, not legacy. The legacy issue I think would be biggest on desktop
[10:49:22] <arnt> the legacy issue is, IMO: do old clients get any access to the stored searches? if we can decide on this, I think the rest of the problem is very much smaller.
[10:49:47] <cromwellian> dave, would users complain if a message appears in more than one mailbox, or do you only think the UI issue is the message appearing twice in one mailbox
[10:49:51] <cyrus_daboo> Sure - for multi-mailbox stuff that could be important, but at that point I would strongly argue instead for a mailstore GUID for each message. That would then be used to uniquely id each message.
[10:50:22] <Dave Cridland> Ray: I think Arnt's already said they complain about seeing messages in multiple mailboxes.
[10:50:47] <eburger> If you have a filter that puts messages in multiple mailboxes, wouldn't you be surprised if it DIDN'T show up?
[10:51:07] <randy> If I recall the proposal correctly, it was to create a server-scope GUID by combining mailbox ID with UIDValidity and UID.
[10:51:20] <arnt> eric, people want another filter: "all the rest - all that's not matched by any other search".
[10:51:41] <eburger> And that one should not have duplicate messages...
[10:51:42] <Dave Cridland> Of course, for VFOLDERs creating usin static searches, messages cannot reappear, so UIDs can be the same as the backing mailbox, so duplicate download can be removed.
[10:51:44] <arnt> sometimes even more than one: "all the rest of the mailing-list mail".
[10:52:03] <cyrus_daboo> Ray - the old Simeon/ExecMail/MessagingDirect client had the concept of multiple 'search filters' within one mailbox - i.e. in your INBOX you would see each "virtual" view as a separate sub-set of messages. So in that case it was multiple views on the same mailbox view, rather than multiple mailbox views. I know a lot of people using that client liked it because they kept asking me to add that feature to Mulberry (which has a single virtual view option).
[10:52:31] <Dave Cridland> Arnt: If each VFOLDER is created with FILTER virtualone, etc, then you can have NOT FILTER virtualone NOT FILTER vitualtwo etc as the catch-all.
[10:52:37] <arnt> Dave Cridland: I have _never_ heard a complaint about messages reappearing in the same mailbox at different times. _all_ the complaints I've heard are about messages appearing both in the vfolder and in the backing mailbox at the same time, and the user needing to look at the backing mailbox.
[10:53:32] <cromwellian> Dave, wouldn't the catch all have to be continuously updated whenever any new named filter is added tho? (if virtualthree is created, then NOT FILTER virtualthree has to be added )
[10:53:39] <randy> Dave--the user needs to look in the backing mailbox why?
[10:54:11] <Dave Cridland> Ray: Yes, presumably.
[10:54:14] <cyrus_daboo> Randy - OK makes sense except that I disagree about include UIDVALIDITY. A message does not change when UIDVALIDITY changes. In any case we are arguing about something I don't think should be in scope right now...
[10:54:14] <randy> To see which message caused a "new mail" flag? And then gets annoyed to see it is a message he/she has already seen in the vmailbox?
[10:54:48] <alexeymelnikov> Randy: exactly
[10:54:54] <arnt> randy, I don't 100% know why. in one example, where I chatted more, it was different.
[10:55:22] <arnt> user had read views, now wanted to read the rest, was annoyed to see all the clutter.
[10:55:55] <cromwellian> trial balloon: what about banning re-appearance. if a message previously was in a vfolder, and disappeared, it cannot reappear. Obviously would require server to keep a tombstone bit around. Also might confuse user if he tried to force it to reappear by toggling flags and it never does so
[10:57:42] <randy> Ray--I don't think that is sufficient to deal with user complaints just mentioned here (such as from Arnt)
[10:57:48] <arnt> don't like that. gets in the way of whole-thread searches, e.g. "all threads with unread messages about foo".
[10:58:26] <randy> It sounds like we need a way for the client to know where a message lives and where it should be displayed, as two separate things
[10:58:55] <arnt> it sounds like we need CONTEXT and for legacy clients do die speedily, right?
[10:59:02] <Dave Cridland> I think we're seeing a repetition of the general problem that virtual folder based techniques simply cannot adequately handle all the use-cases.
[10:59:03] <cyrus_daboo> Ray _ I don't think that will fly with most users. Note we went down this road before with the VIEW extension and the whole dynamic, sem-dynamic, static view debate.
[10:59:11] <randy> The mechanisms would, as a benefit, allow clients to not redownload a message it already has in its cache
[10:59:34] <cromwellian> if folders worked like tagging, you'd just FETCH a message and it would return the list of "tags" (the folders or views) it is a part of, then the client would just add that message to all the views it should be visible in
[11:00:12] <alexeymelnikov> Arnt: +1 on your last comment
[11:00:28] <Dave Cridland> Cyrus: Yes, and that too gets ditched by CONTEXTs - we hand off the question of what flag changes mean to the view displayed by the client to the client.
[11:00:31] <eburger> Are we going to a place that says, "We can't do this because it can't work," a place that says, "We can't do this because there is no 100% backwards-compatible way of doing it," or a place that says, "We don't want to do this."?
[11:00:36] <arnt> do you also +1 on burying IMAP4, since we only need that for legacy clients? ;)
[11:00:56] <arnt> 4rev1 I mean
[11:01:00] <cyrus_daboo> Arnt +100 :-)
[11:01:34] <alexeymelnikov> Let's design IMAPv5 ;-)
[11:01:45] <Dave Cridland> Arnt: Personally, I'm not against virtual folders, I simply don't think they work sufficiently well for all the use-cases.
[11:01:54] <cyrus_daboo> Again - I believe there is no backwards compatible approach to this given that many desktop clients already have local virtual folders.
[11:02:31] <arnt> dave, sure, their redeeming feature is that the stored search is visible from all MUAs.
[11:02:31] <cromwellian> I think we're getting close. As cyrus suggested, almost all of the proposed solutions were considered before. it's like Iraq:), there's no good magical solution to getting VFOLDER out of the duplicate-download-but-works-on-legacy-clients quagmire?
[11:02:59] <randy> Cyrus--but you made a suggestion earlier on an approach that would allow such desktop clients to migrate to the new way which would interoperate with mobile clients
[11:03:16] <arnt> we just have to decide: is LEMONADE's charter to optimise for two-client-using users, or for new-client-using users?
[11:03:27] <eburger> I really, really will be happy with, "Not perfect, but works"
[11:03:43] <eburger> What's the market for each (Arnt's point)?
[11:03:52] <cyrus_daboo> Ray - wrt "tagging" - yes it would be nice when doing a FETCH to also find out what view filters each message matched, rather than having to fire off updates for each filter. That could be done via ANNOTE entries if needed.
[11:03:57] <eburger> Are we looking at 0.05% two-client-users and 80% new users?
[11:04:11] <arnt> eric: you use one client in the office and one PDA, right?
[11:04:19] <arnt> I do not think you're atypical.
[11:04:32] <eburger> I do; that is correct.
[11:04:44] <randy> Eric--if we consider mobile clients to be new clients then we need to optimize for them but in a way that is easy for desktop clients to work with and hopefully benefit from
[11:04:54] <cyrus_daboo> Randy - yes I would like to see desktop and mobile - all clients - converge on a standard way of specifying virtual views. How those virtual views actually get implemented is then another problem.
[11:05:21] <cromwellian> Is our posterboy for VFOLDER, the user who has a new device that supports CONTEXT, but a desktop legacy client that only supports IMAPv4
[11:05:36] <eburger> But I also use server filters to physically move messages and then only look at folders I care about. I tried the RIM way of one big box with Views, but that is really, really stupid, IMHO.
[11:05:46] <arnt> ray, that's who I had in mind at least.
[11:05:48] <cromwellian> in that case, vfolder would seem like a stop-gap
[11:06:00] <cyrus_daboo> So one solution is METADATA entries specifying the search criteria to use for virtual views of a mailbox (or the server as a whole if we get to multi-mailbox stuff). Then desktop clients can do local v folders from that, and we define context for mobile clients to do the same - except context now relies on the METADATA values.
[11:06:51] <cyrus_daboo> Eric - yes one big mailbox seems stupid but there are many times when you want to find all messages from X no matter which mailbox they are in.
[11:07:05] <randy> Cyrus--these METADATA entries get created/updated how? By either client?
[11:07:11] <cromwellian> cyrus, that was my idea. CONTEXT creates the named search criteria, and then VFOLDER would be for desktop users to bind CONTEXTs previously defined in METADATA into folders of their choice, because they are deprived of Lemonade on desktop :)
[11:07:44] <eburger> (To Cyrus) Right, but then I'm doing a, "Find these for me NOW", not "Find these for me ALWAYS"
[11:07:47] <randy> Ray--no reason desktop clients shouldn't implement at least some lemonade features
[11:07:57] <cyrus_daboo> Ray - desktop clients do not need server-side vfolders - they can do all the work locally.
[11:08:00] <eburger> I.e., the named search concept.
[11:09:02] <cyrus_daboo> Eric - OK I see the distinction between NOW (just a regular search) vs always (virtual view).
[11:10:35] <cyrus_daboo> Randy - METADATA entries are updated by the clients. So one client makes a change, and all other clients see that and sync to it - thus you have a consistent set of virtual folders on all clients. PS this is somewhat similar to the sort and thread entries already in METADATA that allow a client to set the default sort/thread criteria so all clients show a mailbox sorted in the same way.
[11:11:30] <cromwellian> I feel like we're treading water
[11:11:34] <randy> Cyrus--makes sense. Also gets around the 'vmailbox provisioning' issue we discussed a while back.
[11:12:05] <alexeymelnikov> Are we converging on CONTEXT?
[11:12:11] <arnt> no.
[11:12:20] <arnt> but neither are we converging on VFOLDER.
[11:12:26] <arnt> we're being fuzzy again.
[11:13:23] <eburger> Yes, I feel we are making progress, NOT :'(
[11:13:29] <Dave Cridland> I see VFOLDER as being expressly for legacy client support. I see CONTEXT as being more useful for both Lemonade and "new" desktop clients.
[11:14:08] <cyrus_daboo> Dave - but legacy clients already have VFOLDER in the form of local virtual mailboxes - why do we want a server side version of that?
[11:14:12] <cromwellian> Our central issue seems to be duplicate download. This seems incapable of resolution for legacy clients (just have to deal with it) and fixable for new clients, but only with a new OUID/GUID identifier
[11:14:14] <arnt> I can agree with dave, with very minor modifications, and I think we have to decide: do we care abotu the legacy issue or not?
[11:14:26] <Dave Cridland> I see Alexey's named filters draft as being potentially useful as the core of the glue that Cyrus is talking about that allows desktop clients to handle there VFOLDERing locally.
[11:14:52] <Dave Cridland> Arnt: yes, but that's not the question - do we care about legacy desktop client in Lemonade? (I think not)
[11:15:04] <arnt> if we care, we can solve the rest with vfolder. if we don't, ditto contexts.
[11:15:15] <alexeymelnikov> I don't think we should care about legacy clients in Lemonade
[11:15:19] <cyrus_daboo> Arnt - we care in so far as we don't break them or serious affect their performance.
[11:15:51] <Dave Cridland> So whilst I'd be delighted to see VFOLDER continue, I don't think it needs to be in Profile Bis.
[11:16:02] <arnt> downloading the 240k-message mailbox I now have in order to emulat the vfolder locally is a performance killer, trust me.
[11:16:42] <randy> We care about legacy clients in that we don't want to make it worse for them
[11:17:02] <eburger> Well, if it's legacy desktop clients, do we really care?
[11:17:04] <randy> But we don't need to give them the benfit of new features
[11:17:05] <Dave Cridland> Arnt: Absolutely. So you implement VIEW (in your case), which is a fine extension for this case, or you implement CONTEXT in both ends, and do it "the new way".
[11:17:18] <cromwellian> I think vfolder needs more justification than just legacy clients, otherwise it is a stop-gap measure whose lifetime useful goes down as clients get upgraded. When Oracle originally put it into P-IMAP we were trying to support legacy mobile clients who may not be upgraded, but Lemonade has different charter/requirements than ISV
[11:18:40] <Dave Cridland> Ray: I think legacy client support is an excellent justification for VFOLDER, but not for putting it in Lemonade.
[11:18:52] <cromwellian> something like VIEW solves the problem, but then of course, since VIEWs don't appear indistinguishable from mailboxes, they don't have the legacy benefits
[11:18:53] <alexeymelnikov> People, I think we are done: CONTEXT it is (in Lemonade profile bis) and VFOLDER can be a separate experimental/standard track/whatever thing
[11:19:38] <eburger> Straw pole (Since we will, of course, take it to the list): What Alexey proposed.
[11:19:41] <eburger> Vote
[11:19:44] <cyrus_daboo> But do legacy clients REALLY support VFOLDER now? How many legacy clients are able to monitor arbitrary mailboxes for changes in an efficient manner? I've not seen many mobile clients but those that I have only know to check INBOX for changes.
[11:20:51] <eburger> (Calling a vote, as the invitation (and a bunch of folks) are leaving in 10 minutes)
[11:21:11] <Dave Cridland> Cyrus: I think they support it more than they do anything else.
[11:21:21] <cromwellian> alexey, can we take as a workitem for CONTEXT2.0 addressing the multi-mailbox-search issue, since last time we had a big vfolder discussion, people seemed to think it was extremely important feature. I know you can do it by just issuing a bunch of CONTEXTs, but perhaps there's a reason to desire a special server support
[11:21:32] <Dave Cridland> (I vote for Alexey's proposal, incidentally).
[11:22:12] <Dave Cridland> Ray: I assume that a multi-milbox search syntax would co-exist with CONTEXT, but if not, that can be inserted.
[11:22:36] <eburger> 2 votes so far for "CONTEXT it is (in Lemonade profile bis) and VFOLDER can be a separate experimental/standard track/whatever thing"
[11:22:53] <arnt> one against, with a heavy heart.
[11:23:08] <cyrus_daboo> Eric - I vote for context in lemonade, and vfolder as individual.
[11:23:28] <eburger> Arnt - can you articulate the issue?
[11:23:49] <cyrus_daboo> But I also think we need to be careful about doing too much in context in one go - I would like to see multi-mailbox done afterwards as an extension.
[11:24:04] <Dave Cridland> I'd actually be keen to see VFOLDER go to PS, incidentally.
[11:24:09] <alexeymelnikov> Multimailbox-search is already a separate draft
[11:24:55] <Dave Cridland> Cyrus: Sorry, yes, that's kind of what I meant - I'd expect a multi-mailbox search to co-exist with CONTEXT, not be part of it.
[11:24:56] <alexeymelnikov> draft-melnikov-imapext-multimailbox-search-01.txt
[11:24:57] <randy> I'd like to see how multiple mailboxes can fit into context, even if we agree to remove it for the first version.
[11:25:25] <alexeymelnikov> Randy: check draft-melnikov-imapext-multimailbox-search-01.txt
[11:25:27] <arnt> eric, I feel (this is feeling, pure feeling) that we're going to be sitting here treading water talking fuzzily at each other until we decide for CONTEXT. not because of CONTEXT's merits or VFOLDER's demerits. I don't like that feeling.
[11:25:27] <randy> It will need to fit in a natural way, including the ability for clients to know if they already have a message in cache
[11:25:56] <randy> Arnt--what can we do to stop being fuzzy?
[11:25:57] <eburger> Randy - CONTEXT moving forward, VFOLDER "something else"??? your 'vote'
[11:26:18] <randy> Eric--yes that is OK but I also want to understand the one objection so far
[11:26:40] <arnt> I'll yield. good+moving is better than best+stalled.
[11:26:44] <cyrus_daboo> Randy - agreed to the extent that we should not design context such that multi-mailbox is hard, so we do need to keep it in mind.
[11:27:29] <randy> Arnt--before yielding, is the objection based on context or is it that we are still being fuzzy?
[11:27:51] <arnt> our being fuzzy.
[11:27:53] <cromwellian> can I abstain? :) as editor of vfolder, I am still in favor of it, but I am in favor of it freasons that may be short-term. For Lemonade, I tend to want to look to the future
[11:28:23] <randy> Cyrus--if multi-mailbox support means we need to include a GUID or its moral equivalent, such as the mailbox ID, UIDValidity, UID triplet, then we need to see how that fits in before we decide to remove it for now
[11:28:47] <cromwellian> I think maybe Arnt and I and others who are interested can work on it as a separate item not as part of profile
[11:28:58] <randy> Arnt--are we being fuzzy on requirements or on the technical aspects of context/vfolder?
[11:29:19] <cromwellian> I would still like it if it was kept as a tracked document by lemonade
[11:29:22] <arnt> both, but requirements more.
[11:29:46] <alexeymelnikov> Ray: that would be fine with me
[11:29:58] <eburger> It is half-past the hour. How does this sound as a summary to the list:
[11:30:20] <eburger> Go forward with CONTEXT as part of LEMONADE bis. VFOLDER as experimental.
[11:30:28] <Dave Cridland> I have to admit, I thought we'd been over the technical aspects of both several times. I'll agree I'm not convinced we fully understand the requirements of the real-world.
[11:30:40] <randy> Maybe we need a clear draft on what problem we are trying to solve, to make sure we don't do anything in a fuzzy state
[11:30:53] <eburger> (And if you come up with objections, might as well post them to the list)
[11:30:56] <Dave Cridland> Eric: As I've said, I'd prefer VFOLDER to be PS.
[11:31:08] <eburger> Randy - what don't we know?
[11:31:22] <eburger> PS implies we expect lots of implementations. Do we?
[11:31:45] <cromwellian> i think there are atleast 2 so far
[11:31:51] <randy> Eric--Arnt says we're still fuzzy, and I admit I'm not sure I understand the problem and desired solution
[11:31:52] <alexeymelnikov> We can decide on PS versa Experimental later, IMHO
[11:32:03] <eburger> Agreed (with Alexey)
[11:32:19] <alexeymelnikov> I am Ok either way. But let's not be stuck on this
[11:32:37] <randy> So perhaps the context draft can include a nice clear statement of the problem and requirements?
[11:32:48] <randy> Maybe Arnt can contribute text?
[11:32:53] <alexeymelnikov> Randy: Sure
[11:32:55] <eburger> THAT would be good.
[11:33:01] <arnt> I have to go approximately this very moment. I'll look at the screen later.
[11:33:06] <Dave Cridland> More writing? Argh!
[11:33:08] <eburger> Me, too.
[11:33:12] <randy> (and of course I'm happy to help that draft in any way I can)
[11:33:27] <eburger> I'll leave my window open, but I'm not here.
[11:34:15] <alexeymelnikov> Randy: I think you've volunteered to write some text on the problem and requirements ;-)
[11:34:37] --- eburger has left
[11:34:57] <randy> I can take a stab at it. If nothing else it will show where I don't understand the problem :-)
[11:35:45] <cromwellian> dave, does CONTEXT require a client to implement an imap search parser/search locally. I ask, because I was thinking about a message which matches 2 different CONTEXTs with notify. How would the client know which named filters that the message matches? Should the notify response specify the named filters that were matched?
[11:36:13] <Dave Cridland> Ray: It tells you.
[11:36:22] <cromwellian> oh ok
[11:36:36] <Dave Cridland> Ray: The search correlator tells you which SEARCH command caused the ESEARCH response.
[11:38:20] <Dave Cridland> Ray: FWIW, if you do implement an IMAP search parser, and do search locally, you can do pretty good emulation of CONTEXT locally. It's more expensive, and the biggest loss is probably PARTIAL, for most things.
[11:40:29] <cromwellian> hmm, i didn't see the correlation thingy in either the notify draft nor the imapext-filters draft, but I'm lacking sleep, so maybe my brain glossed over them
[11:41:10] <Dave Cridland> It's in ESEARCH. RFC4731
[11:41:15] <cromwellian> oh, is it the TAG thingy
[11:41:23] <Dave Cridland> Yeah. Sorry. :-)
[11:42:52] <cromwellian> ok, nvrmind. Yeah, I think desktop clients probably will discover named filters, and offer the user the ability to do offline local search, or online search + notification if they want it. of course, it's probably a dream, since most popular imap clients (thunderbird, Apple Mail, etc all) tend ot implement 1/10th the features of the full IMAP standard
[11:43:30] <Dave Cridland> Well, true. And users select by the quality of the icons.
[11:44:09] <cromwellian> Polymer just needs new jellybean styled 24-bit icons then.
[11:44:13] <cromwellian> :)
[11:44:41] <Dave Cridland> I've used prettier icons for Telomer (Nokia 770 port)
[11:47:00] <cromwellian> polymer is python right? does that mean you're running an embedded python on the 770??
[11:48:11] <Dave Cridland> Ray: Yes. That's been out for a while.
[11:49:02] <Dave Cridland> Ray: No really embedded, either, just slightly trimmed around the edges.
[11:50:59] <cromwellian> cool. I think my brain is starting to drift now. I'm gonna go nap and then get some coffee. I had a few questions about context, but I'll email them
[11:51:42] <Dave Cridland> Sure.
[11:52:04] <cromwellian> 'nite :)
[11:52:11] --- cyrus_daboo has left
[11:52:14] --- cromwellian has left
[11:58:56] --- kmurchison has joined
[11:59:21] --- Dave Cridland has left
[12:14:53] --- randy has left: Logged out
[12:37:11] --- kmurchison has left
[13:05:30] --- alexeymelnikov has left
[15:10:50] <arnt> excxsd
[20:35:37] --- Glenn Parsons has left