>
> On Sat, Feb 07, 2015 at 02:23:56AM +0100, mobi phil wrote:
> > <[email protected]> wrote:
> > > from what i remember, i found only the global message id interesting,
> to
> > > replace the custom X-TUIDs.
> > >
> > well, that may be technically an added value, but not that much from the
> > user point of view, or?
> >
> actually, from a "technical" point of view it would be an "unnecessary"
> complication, because it works just fine as it is now.
>
it would though fit into the category of metadata like the labels. The same
applies to thread id.
The idea is to have the simplest way to store this information to a
metadata file that would have the base name like the message file name.
Another level of complexity, to be able to change this metadata and update
the source (this probably applies only to labels)
> > While I do not know how many people are using the same time labels on
> > gmail and isync, for sure lot of people are using labels. Now if you
> > use mechanisms like isync implements would be awkward to store the
> > same message in several places for different reasons like storage,
> > indexing etc.
> >
> please explain how recognizing labels helps with that, and how guids
> don't.
Well, "would be awkward to store the same message in several places" needs
different stages to implement. The first one, the most important one, is to
download the metadata (mainly the labels) by the same applicaiton. The
second phase, less important to have it in isync, to mirror the virtual
directory structure with symbolic links to avoid message duplication".
Did not understand what do you mean recognizing labels, but in the second
phase you would just create a symbolic link to the original message under a
directory with the name of the label, that is all.
Labels help you to classify your information in orthogonally different set
of categories. Personally I am using isync mainly for archiving. I am
creating set of labels on gmail web interface with different meaning
-> importance: high, low
-> urgency: high, low
-> location: etc. etc.
-> client: etc. etc.
> > > i think a much better approach would be implementing only label
> > > (keyword/custom flag) support, and let the higher-level software do
> > > the virtual folder management.
> > >
> > Sorry, but not sure if I correctly understood it. For sure modifying
> > the original mail message text by adding keword/custom flag is
> > probably not the best idea.
> >
> coming up with an approach that obviously sucks and then assuming that
> it's exactly the way it would be implemented is certainly the way to be
> taken seriously.
>
sorry, did not really understand this exactly
>
> the topic of custom flags has been discussed on this list multiple
> times. read the archives.
>
what would we both gain if I spend now hours to search and to read, if you
are not open to any solution? If you tell me for what you are open, I can
adjust my next step to that.
> why google chose to invent x-labels instead of simply using imap
> flags/keywords is beyond me. it is technically exactly the same thing,
> and supporting it just adds seemingly pointless work.
> this is entirely orthogonal to whether they additionally expose the
> labels/keywords through virtual folders.
>
That is beyond my knowledge, and honestly incentive to understand.
To resume, a simplified version of the suggestion would be to create a
simple mechanism for which imap extension could be mirrored on both sides
of the channel in a transparent way. For instance on the maildir side, one
could just have a list of files with the same base name as the message file
inside the maildir or outside the maildir in, probably best json format,
containing the gmail msg-id, label list, thread id.
A simple plugin mechanism would be enough, to make it no so much hackish.
Such a plugin mechanism would call a set of registered plugins for each
message providing as parameter both sides of the channel. The plugin would
just use the IMAP source to make custom calls for gmail labels or anything
new will be invented, and add an extra json record to the sink file.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
