<[email protected]> wrote:
> On Mon, Feb 02, 2015 at 02:18:33PM +0100, mobi phil wrote:
> > > > I would like to use this opportunity if you are planning to support
> the
> > > > features listed on
> https://developers.google.com/gmail/imap_extensions
> > > >
> > > some of them.
> > >
> > is there a list of them? Can you please share it?
> >
> 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?
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.
> > > > managing correctly labels as labels and not as directories would
> > > > be [c]reate to avoid message duplication on client side. Symbolic
> > > > links would be probably the greatest
> > > >
> > > that's harder than it seems, as it breaks several abstraction layers.
> > >
> > had just a basic look into the software. Basically you have drivers for
> > different sources and sinks. Most of the time a sink is also a source.
> You
> > create channels between them. What about just creating some plugins to
> add
> > additional "decorators" for the sinks sources and connect the
> "decorators"
> > if they are available on both sides? I think this would simplify future
> > additions to the protocol or some implementation specifics.
> >
> that solves only half the problem.
> you want to physically link the mailboxes in one store, declaring one to
> be "real" and others to be "shadows".
> getting this assignment through the channel (e.g., via labels, which are
> just imap flags on steroids) seems like the minor issue here.
>
> 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. If the original message would be encapsulated into a container
to which additional information would be added would be another idea, but
then clients like mutt would have problem to understand it.
Well, anyway for the initial phase, would be interesting to have the
information in any form, maybe as a comma separated list of labels into a
file having the same base name as the message file, with some trivial
extension.
I remember there were some patches around that tried to deal with the
problem.
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
------------------------------------------------------------------------------
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
