[Kde-pim] Handling virtual collections in applications

[Stephen]

Volker Krause <vkrause <at> kde.org> writes:
> Let me start with a general note on this stuff: As we don't really have 
> implemented search yet, virtual collections are largely unused. The 
> Item[Un]Link jobs have been implemented on request of Tom and Dmitry who 
> wanted to use virtual collecitons for the Nepomuk tag resource and the KRSS 
> stuff. Not sure about the latter, the tag resource might as well be the only 
> current user.
> 

Yep, they might be largely unused now, but they'll still have to be supported
throughout akonadi now that it's been released.

> > Something that came to mind while implementing the models stuff is how the
> > model should handle virtual collections. I think it should not be possible
> > to move, or insert an entity from a virtual collection using regular user
> > actions (like drag and drop). However, I don't think there's currently any
> > way to know if a particular collection is a virtual collection. Do we need
> > a Collection::isVirtual()? Does a collection know that it's virtual?
> 
> There is no way to detect that currently, which is also a problem for the 
> server side implmentation. Currently its a big hack using hardcoded resource 
> names :-/

Hmmm, damn. Does the server side really care if a Collection is virtual? On the
application side it might be possible to ignore the issue. As Ingo writes, there
is probably no difference with how a user interacts with a collection of links
to items and a collection of real items.

> I agree with Ingo, moving from a virtual collection has its use-cases. In 
> fact, dragging to a virtual collection has as well, eg. in case of the tag 
> resource. But that is probably impossible to handle in a generic way.

Hmm, true. Do you have any more information on what a tag resource is?
Is it something like a resource of virtual collections which shows for example a
maildir structure organized by tag instead of by akonadi collection? This might
be better as a proxy model. Has anyone put any thought into how it will work for
applications?

> > Virtual collections can't contain collections as far as I can see (there is
> > an itemLinkJob, but not a CollectionLinkJob). Is there a usecase for
> > (dis)allowing that?
> 
> Good question, I can't think of a use-case for allowing it at the moment. 
> Somewhat related is the question of cascading virtual collections. That makes 
> IMHO more sense, see eg. the tag resource. Mixing both could get very 
> confusing though.
> 
> > Is there actually anything special about virtual collections, or is it
> > simply any collection which has an item linked in it? In the same way that
> > I can symlink files and directories in my filesystem. Can I link an item to
> > any collection?
> 
> Currently that is not allowed.

How so? The server decides whether it's allowed based on the hard-coded name or
something?

> So, such links would be purely local, not something you 
> might expect in your IMAP/Groupware folders. Given that I don't see a 
> use-case for that yet, I would suggest to not allow it.

My understanding was that any linking stuff was purely local anyway. I can't
think of a reason to communicate a link operation through a resource.

I'm not sure I understood what you wrote about inter/intra resource links
though. If I do new LinkItemJob(item, collection), do item and collection have
to be in the same resource?

> 
> > What happens if I list a collection which contains (sym)links to items?
> > Will the list job return a list including linked items? Will I have any way
> > of knowing whether the returned item is really in the listed collection, or
> > if it is just a link to an item in another collection?
> 
> Currently you cannot detect the difference at all, list jobs return both, 
> items and links. It would be possible though, if we do not allow mixed 
> collections and add a way to detect if a collection is virtual. 

Right. We'll have to figure out if we have any use case for the mixed case. If
we don't have, I think this is a better solution. 

> Also, having 
> the full parent path available in the item as we discussed elsewhere would 
> allow such a check, even in the mixed case.

Not really. 

If I list a collection, the ItemsRecieved signal contains the items, but doesn't
tell you what collection was being listed. You could check its ancestors, but
that would only tell you the real parent. Even if you also make all virtual
parents available to the entity (a bad idea IMO. Should really only give real
ancestors), you wouldn't know whether the list job was started on it's real
parent or one of the virtual ones.

A similar issue was solved in the EntityTreeModel by attaching the id of the
parent collection to the job as a property. See the fetchItems method

http://websvn.kde.org/trunk/playground/pim/akonadi/akonadi_next/
entitytreemodel_p.cpp?view=markup

That would mean this hack would be necessary throughout akonadi any time you
want to list a collection which might have linked items.

I think the solution is this (if the server can support it):

Make it so that there is nothing special about virtual collections. Any
collection can contain links to items. Maybe allow links to collections too if
the virtual inbox case I mentioned will be supported.

Make it so that the list job also emits the collection that was listed to start
the job. The reciever of the signal can look at the parent of the item to see if
it's really part of the collection, or just a link.

All the best,

Steve


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/