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

[Michael J Rubinsky]

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...

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.

> 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.


-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20130703/d1798501/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130703/d1798501/attachment-0003.bin>