I think the original script was quite a mess, indentation broken,... And
the most important thing: it had the logic broken.
It splitted the notes by old/new in the cron job, which is wrong, because
this is a comulative script. Over the time, older notes wouldn't be marked
as such.
What I've done is to create a database with all notes. This may seem a slow
process for the first time, but following runs are faster.
true, although I was planning something to fix that over the weekend, I might
now be able to look into the auth code and get RFC working.
Sorry, I didn't knew you were working on the script.
It kinda annoyed me that it uses the disk a lot, making my music hang..
and using up quite some space
Its less than 4 MBs :) The revcheck DB takes more than 11 MBs.
The first time is slow, because of sqlite journaling. Disabling it, speeds up the process, but its not good for following updates.
So, the presentation code shouldn't be in the cron script. Now we have two
choices: generate the old DB schema, collecting data from the new one; or
simply cache the results. The orphan notes cron job generates a static
file. The same thing could be done with this script.
Thinking some more about this script, it's usage etc
Making it a static page seems like a very good option.. that I didn't thought
about that before.
It does require both scripts to be one, and also disables debuging, or we use
php to write the file and still output some useful debug info :)
Yep, we can write the ouput from the php script. Anyway, we can keep the two scripts. One for updating the DB, and the other to generate the output. Do you want me to do implement that, or you take care of that? (I'm going on vacations this weekend, but I can do it next week).
Nuno