Re: superkaramba, categories, XML

On Wednesday 22 of October 2003 21:23, Peter Bienstman wrote:
> There is some runtime overhead because Dave doesn't want categories in the
> core, (...)

Hey-hey, it's not that I definitely don't want categories in the core. :)
I just prefer to focus on some other things and I totally didn't like *my* 
last categories implementation (I must admit: I coded it carelessly not 
thinking too consciously about user needs, because I personally don't feel I 
need it - so I coded it badly just to have it off mind...)

Code and project is open - anyone can submit own categories implementation, 
and I believe people who need/want it have better ideas and motivation to 
implement them well.

And one more thing: if most of you don't agree with me on something: I will 
generally follow your will. I prefer democracy. :)

Back to categories topic:
What about that 'id' field proposed by Richard Hoberman?
For now MemAid core could be dumb about it, just store it, load/save.
But front-ends could use it as (also) category field
(e.g. [category name|some-user-description-aka-id-field]),
and later *maybe* the core could use it more awarely as category field as 
well.
What are your thoughts?


And by-the-way: in idea - instead of playing with activating/deactivating 
categories: there could be a dialog with regular expression.
E.g. possible dialog:

"What elements you want to learn?
Element id/category field have to contain: ________
Element id/category field have to not contain: _____
Elements that contains (in question/answer): _____
blah blah (any other ideas): _____  "

Where ____ is a simple regular expression (alphanumeric +  *)
Could be more powerful and usefull (think about activating/deactivating 
hundreds of categories).
But it's just an idea.


> so I have to do some extra book-keeping. What would really help a lot
> (short of implementing categories in the core ;-) ), is a trivial change to
> the core: just add a 'note' string to each element:
>
> struct elem {
>         u_short tm_t_rpt;
>         char *q, *a;
>         char* note;
>         ...
> }
>
> The core doesn't have to do anything with this field, not even write or
> save it to file. It's just a place where a front-end can park any
> information it wants to attach to an element.

Ok, this won't be a problem as it doesn't add any overhead in the core.
But isn't it doubling "id" field? Or you need a separate (from 'id') field?
Or maybe 'id' field is a bad idea? ;)


DC



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54