[dev] [commits] Horde branch master updated. f61fdaee6bb5fee15abe792219b02a0947925028

[Chuck Hagenbuch]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> The branch "master" has been updated.
>>>> The following is a summary of the commits.
>>>>
>>>> from: 5643dee22aa524776bd6caf14625c3acc3858002
>>>>
>>>> f61fdae Right now _getRelatedTags() is the difference between my  
>>>> task list loading in .5 seconds and it taking 4-5 seconds to  
>>>> load, even after the Horde_History cache improvements. It also is  
>>>> getting tags that aren't from the current view because Future  
>>>> tasks aren't accounted for.
>>>>
>>>> -----------------------------------------------------------------------
>>>>
>>>> commit f61fdaee6bb5fee15abe792219b02a0947925028
>>>> Author: Chuck Hagenbuch <chuck at horde.org>
>>>> Date:   Wed Jul 3 00:33:57 2013 -0400
>>>>
>>>> Right now _getRelatedTags() is the difference between my task  
>>>> list loading in .5
>>>> seconds and it taking 4-5 seconds to load, even after the  
>>>> Horde_History cache
>>>> improvements. It also is getting tags that aren't from the  
>>>> current view because
>>>> Future tasks aren't accounted for.
>>>>
>>>> I think if we want to keep the related tasks top bar, we need to  
>>>> put that list
>>>> together as we go through the list of tasks, where we're already  
>>>> fetching the
>>>> tags for each task and displaying them next to each one. That'll  
>>>> avoid a *lot*
>>>> of unnecessary queries.
>>>
>>> This may be true, but can you wait until there is some fix in  
>>> place before removing it in the stable git branch? This way, we  
>>> won't accidentally remove this functionality from the next bug fix  
>>> release.
>>>
>>> FWIW, this is also the same mechanism that we use in all the apps  
>>> that use tags-as-navigation such as Trean and Ansel. I think we  
>>> need to improve either Content_Tagger or Core_TagBrowser instead  
>>> of moving the browsing functionality out of it and into the  
>>> application-land code.
>>
>> Yeah, I saw that it was the same mechanism, and agree it needs to  
>> be improved. Is this really that useful a feature right now though  
>> that we need to keep it in exchange for pages loading 8x slower? It  
>> just seems to filter the existing view, and I'm not sure that  
>> filtering tasks by multiple tag criteria is that useful. Obviously  
>> there might be another use case out there that heavily uses tagging  
>> to organize a ton of tasks, but anyone doing that right now is  
>> going to spend a LOT of time waiting.
>
> Well, I use it :)  I use it as a quasi GTD workflow. It allows me to  
> easily do things like "show me all the tasks that I can do at home  
> (since I have a "Home" tag), now , out of those tasks, show me the  
> tasks I can do that are related to TaskOne, now show me the "next  
> action" that needs to be taken on that task etc... It's something I  
> started doing when I was using RTM and the reason I added tags and  
> smart lists to Nag in the first place - I felt dirty using a  
> non-Horde solution ;). By naming my "project tags", "location tags",  
> and "requirement tags" a consistent way it is a very versatile way  
> of diving into a task list depending on your current "context" - the  
> combination of things like current location, tools available,  
> project due dates etc...

Okay, that makes sense to me as a use case.

> I don't really see any slow down; the task lists load fine for me in  
> approximately the same amount of time with or without the tag  
> browser, but maybe that is because I don't use a ton of different  
> tags, just a consistent handful. Though I do see that there are  
> improvements that need to be made.

I don't have a lot of tags in Nag, but for each one, it triggers a  
listTasks() call again, which reloads the full task list, which hits  
Horde_History, etc. Things got better when I added memcache caching to  
Horde_History, which was my first attempt to track down the  
slow-loading task list page, but even if they're all fast memcache  
hits, ~5,000 Horde_History lookups (which is what I see when the tag  
browser is loaded) is just slow.

So if we can't make this something that's calculated over the list,  
which would make it one-pass, I think we need to modify Nag_TagBrowser  
to use something else to do the searches so that it's not doing a full  
tasklist load. Is that just dropping in another object instead of  
Nag_Search inside Nag_TagBrowser?

>> Another option that doesn't preserve multi-tag filtering would be  
>> to show the tags in the sidebar like we do for Trean - that'd be a  
>> much lighter query at least.
>
> Yeah, I saw the sidebar tags in Trean but was it doesn't currently  
> work for me. It's probably just a rampage related rewrite rule I  
> need to add to lighttpd.conf to get to work. Anyway, we still also  
> have the tag browser there as well (which is how I still use Trean),  
> so I'm not sure how that is running faster for you (if it is - not  
> sure if that is what you were suggesting). Either way, I would say  
> this isn't an option for Nag since multi-tag filtering is a pretty  
> big must-have for me (and at least some users since a few bug  
> reports came in related to it). I'd think that even for Trean we'd  
> still want to keep the tag browsing as it makes sorting through tons  
> of bookmarks much easier. To me, we'd be losing both a pretty big  
> advantage of using tags and something that sets our implementation  
> apart from most other tag implementations - the ability to  
> "navigate" based on them.

Yeah, you're right, it's a different use case.

-chuck