Re: categories in core

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 13 October 2003 22:50, David Calinski wrote:

> All categories are activated by default - now.
> But if I will implement saving/loading active categories in core, and later
> (as an user) I will de-active some categories in a GUI version,
> then yet later I will use console version (from a different location - I
> sometimes work remotely on my computer, but in console) I won't be able to
> use some categories.

Well, I think this is more a useful feature than a bug, but you're right, it's 
subject to interpretation and not such an important issue.

> I think we think about a bit different use of "active" categories. ;)

No, I don't think so, but perhaps there's some confusion from the word 
'persistent'. I didn't use persistent in the sense of something that was set 
in stone and wouldn't change for thousands of years, but rather in the 
computer science sense of the word, as a piece of state information that is 
saved to disk when the program exits, and that can be retrieved when the 
program is started again. Of course you can activate and de-activate 
categories as often as you like.

> Hmm. I consider "scheduled repetitions" to be very important - I want to
> have always all categories activated in this mode as I want to have reviews
> exactly on the scheduled day.
> At the same time I may want to worry about specific category/topic that I
> need to learn for next few days (e.g. exam) - so in "Force ahead of
> repetition" mode I may turn only one category.
> I think it is useful. :)

OK, you've convinced me here. I can see now that that would be a really useful 
thing to have.

So, the question is whether to implement 'persistence' in the core or in the 
clients. Well, since all the clients dealing with categories will want some 
form of state-saving anyhow, I think it's best implemented in the core to 
avoid duplication of effort, code and file formats.

But can we make the system general enough for learning modes that are not 
implemented by all frontends? What about the following idea: we define an ID 
for each of the learning modes, i.e.

optimally_scheduled = 0
repeat_ahead_of_time = 1
....

If there's a mode that is only implemented by 1 client (e.g. drill_badly_known 
in the superkaramba), you can also assign it an ID. Since you'll be the only 
person handing out these ID's, there's no risk of clash.

Then, the category information that is saved to file looks something like 
this:

category name
category number

# mode ID  - active?

0  true
1 false
....

Then in the core there are functions like

ma_set_category_active(mode_id, bool)
bool ma_is_category_active(mode_id)

So, learning modes that are implemented in the core can use this mechanism, 
but it's also available for frontends that have different learning modes.

I think this has a number of advantages:

- -it avoids duplication of code, effort and file formats between the frontends
- -it's general enough to deal with fancy clients and exotic learning modes
- -it does not disturb clients that don't implement all learning modes.

What do you all think?

Peter

- ------------------------------------------------
Peter Bienstman
Ghent University, Dep. of Information Technology
Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium
tel: +32 9 264 34 45, fax: +32 9 264 35 93
WWW: http://photonics.intec.ugent.be
email: [email protected]
- ------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/i68G4dgPAIjyquoRAjXDAKCV3UrIQ0GaudJQMRtwGShvyBE1zwCfQXrb
fN0OXYM8aLkf+ZPGpHdCyuk=
=X0Uq
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php