Tickets :: Comment on [#2011] Add Virtual Contact Lists

* Your Email Address
* Spam protection	Enter the letters below: . ..__ .___. .._. \|\/\|[__)[__ \|\/\| \| \| \|\| \| \| \|_\|_
Comment	> Well, on one hand, you would be consistent with IMP if you used a > Virtual Group analogy. > > > > But.... > > > > I tend to think that it would be truly innovative to due away with > the whole Virtual tag and make folders and groups and other virtual > entities be transparent to the end user. What is a traditional IMAP > folder? Its generally a collection of associated messages in a > folder (or a single file) on a mail server. Does a user know that? > Nope - they just see a representation of that. So blur the whole > concept of folder - move it away from mapping physical units on a > mail server, to logical grouping of messages - there's no need to > draw attention to the fact that one is virtual and another is not. > > > > For groups, there's no need to distinguish between a hard coded list > of addresses, and a list that is dynamically generated real-time, > from multiple sources by designating one as Virtual and one as You > Typed These In Yourself :) The only thing that is needed is a way > for a user to assign labels to what are effectively search queries. > Again, it doesn't matter how the various discrete entries are > physically stored - we're after the logical representation of them to > the user. > > > > I'll explain the context of the request, so you can maybe better > understand how I ended up with it. > > > > Our legacy email client (legacy is being too kind) supports the > concepts of Address Books and Address Groups. An Address Book is > physically a file, that contains addresses or entires. An Address > Group is an entry that contains a collection of addresses. And its > fully decentralized - add an entry to whoever is in charge of keeping > the master copy and send the new file out to all employees, hope they > install it properly, and too bad if they happen to be using something > else for email (like, oh, say IMP). > > > > Fast forward to a transition to IMP and Turba on FRAMEWORK_3. > Paradigm shift the concept of an address book from being a physical > file, with entries, to being a configured source in turba with hard > coded search critera. You end up with the same result as you had > before, but its fully centralized, real-time and requires no user > intervention. Because we are storing additional information about > people, like titles, building location, etc. we'll also have another > source that makes available address groups, which are really just > hard-coded searches based on title, location, etc., that we think > will be useful to people. > > > > But people will still want a subset of those groups, so thats where a > "Virtual" Contact list comes in. It places in their power the > ability to create an entry with user-definable search criteria. And > they don't need to maintain it - when we add a new person in a > certain building that is a support staff class, for instance, if they > have that search criteria setup for all support staff in that > building, the user would be returned with their results. > > > > So thats what spawned the idea and a history of address books here. > > > > Its a continuim: > > > > localsql (w/ personal address books and point n click contact lists) > -> Sympa mailing lists w/ LDAP queries (for access control - not > everyone should be able to send their pet messages to all of our > users, using a simple alias) -> LDAP directory (all employee entries) > > > > The addition of a Virtual Contact list would cover just about every > possible way that an individual would want to keep or access > individual or group addresses. The only thing missing at that point > would be a bonafide Turba Share, so I could share my logical grouping > and personal entries with others who might use them, with the end > goal being non-duplicative address data. > > > > So back to the question, after that ramble. Its a design decision - > if you wish to keep distinguishing between virtual and real, then > this would be implemented as Virtual Contact Lists. My argument > would be that everything is just a representation of something else, > so take a blackbox approach behind the web GUI and present them all > as equal to the user. In other words, an alias that a user has setup > that consists of a search for all staff in building Y who are in > department X would look no different than a list they built by > searching for individual addresses and putting them in a contact > list. IMP is blind to whether the list is "virtual" or not. So make > it be that way to the Turba user as well.
Attachment
Watch this ticket

Saved Queries