Closed Bug 343160 Opened 18 years ago Closed 15 years ago

Re-examine category storage mechanism

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jminta, Unassigned)

Details

We should re-examine the way we store categories, as the current method has several holes.  shaver has suggested using some JSON-serializing, in place of our current Array.join(',').  I'm really wondering whether we need to even store these in preferences at all, instead of simply mining all categories from existing events.  Part of this depends on whether/when we switch over to a tags model instead of categories.
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
Does this bug still apply? I believe it was fixed with bug 321010.
(In reply to comment #2)
> Does this bug still apply? I believe it was fixed with bug 321010.

Categories are still stored in preferences and not in an easier accessible 'database', so I think the bug still applies.
Version: Trunk → unspecified
(In reply to comment #3)
> (In reply to comment #2)
> > Does this bug still apply? I believe it was fixed with bug 321010.
> 
> Categories are still stored in preferences and not in an easier accessible
> 'database', so I think the bug still applies.

Philipp asked over IRC for a reason why we need to store categories somewhere else than in the prefs.

Answer: I don't know. But it would be nice to have a more dynamic approach including categories from the events of the (remote) calendars, not just the ones created in Lightning/Sunbird. But this should be handled in a different bug.
Maybe we should examine how firefox stores the tags and do something similar? I guess this only makes sense if we have some super smart way to remember all categories from imported files, which may in turn make more sense if we have gloda for calendar items.

What do you think we should do with this bug? Close it in favor of the different bug that takes care of remembering tags from files? Or maybe make this depend on that bug?
(In reply to comment #5)
> What do you think we should do with this bug? Close it in favor of the
> different bug that takes care of remembering tags from files? Or maybe make
> this depend on that bug?

I think we should close this bug in favor of a (still to be filed) bug for a more sophisticated approach using tags/categories in a more dynamic way.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.