233973 - logs should be separated in different files by day

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, enhancement)

Description

[Fergus Kelley]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Chatzilla currently logs everything from each channel/server/query view into a
single file for each thing like this:

profiledir/chatzilla/logs/moznet,%23chatzilla.log (for channels)
profiledir/chatzilla/logs/moznet,littlezephyr.log (for user views)
profiledir/chatzilla/logs/moznet.log (for server views)

The problem is, the files are always the same, and for busier channels, the size
can get quite large, making them very cumbersome and heavy.

Thus I think CZ should make each view its own directory, and name the files
daily, logging all of that days info into that file. For each of the examples
above, here's my preposed format:

profiledir/chatzilla/logs/moznet,%23chatzilla/moznet,%23chatzilla-2-11-04.log
profiledir/chatzilla/logs/moznet,littlezephyr/moznet,littlezephyr-2-11-04.log
profiledir/chatzilla/logs/moznet/moznet-2-11-04.log

The format for March 28th logs would be:

profiledir/chatzilla/logs/moznet,%23chatzilla/moznet,%23chatzilla-3-28-04.log
profiledir/chatzilla/logs/moznet,littlezephyr/moznet,littlezephyr-3-28-04.log
profiledir/chatzilla/logs/moznet/moznet-2-28-04.log

This way, the files don't get as large, but they are still roughly together and
still reasonably organized...

Reproducible: Always
Steps to Reproduce:

Comment 1

[James Ross]

A few people have suggested this, confirming RFE.

Comment 2

[Constantine A. Murenin]

Please, use the ISO8601 date stamp (also known as SQL date stamp) in the
files-names, i.e. YYYY-MM-DD. This way files will be sorted properly and we will
not have any intl issues. Or one may also create a user_pref for this matter,
but please, set it to YYYY-MM-DD by default. 

For more details and advantages of ISO 8601, see
<http://www.cl.cam.ac.uk/~mgk25/iso-time.html>.

Comment 3

[James Ross]

How about this: a single pref to dictate the log file location, with the
following expansions:
    %s  - server or network name.
    %c  - channel/user name (blank for network views)
    %v  - full view name, (basically "%s,%c")

Then %y, %m and %d for the date.

The default can be, for example, profilepath/chatzilla/logs/%v/%v-%y-%m-%d.log".

I don't think I can fix this bug with the current logFileName prefs, so they may
disappear - though perhaps I could make the default value for that pref be
generated /from/ this global pref - but you could set them to fix one view to
one log file.

Comment 4

[James Ross]

Attachment: Adds 4 prefs to control log locations.

This makes the 4 types of log have their own pref controlling the location,
with %network%, %channel% and %user% replacements, as well as date and time %
codes. The logs are also all rooted based on logFolder now, which can be moved
away from the profilePath pref.

Note that log filenames are generated (unless explicitly set) as needed, and
thus the date/time used will be that at the time of opening the log.

Comment 5

[chris hofmann]

Comment on attachment 143248 [details] [diff] [review]
Adds 4 prefs to control log locations.

a=chofmann for 1.7b

Comment 6

[chris hofmann]

Comment on attachment 143248 [details] [diff] [review]
Adds 4 prefs to control log locations.

er, lets hold off and do this feature early in 1.8a.  trying to shut down and
get  some beta bits out the door.  sorry about the confusion.

thanks

Comment 7

[Constantine A. Murenin]

Comment on attachment 143248 [details] [diff] [review]
Adds 4 prefs to control log locations.

Silver, could you replace ".log" with ".txt" extension? I think, .txt will be
friendlier with systems that judge the content of a file by extension.

Comment 8

[James Ross]

Attachment: Updated version of patch

Comment 9

[Robert Ginda]

Comment on attachment 160975 [details] [diff] [review]
Updated version of patch

I think the way you're doing the replacement will run into problems with
encoded chars.	If you replace %channel% with some channel that encodes to
something with a "%d" in it, for example, then the shortcodes are going to
stomp it.

Also, I've been leaning toward a lambda replace in situations like this, to
avoid the multiple .replace calls.

If you did the replace as...
file.replace(/\$\(([^))]\)|\$(\w), f);
The vars could be expressed as $(network) or $d.   Because it's done with a
single replace() call, you don't have to worry about replaced text causing new
matches, either.

Comment 10

[James Ross]

Attachment: Updated patch based on comments

Some great comments, rginda - here's an updated version that uses $(network),
etc. as suggested, plus a lambda replace function.

Comment 11

[Tuukka Tolvanen (sp3000)]

typos :)
>+            dd("Unknown long code: " + longNane);
>+            dd("Unknown short code: " + longNane);

Comment 12

[Robert Ginda]

Comment on attachment 162052 [details] [diff] [review]
Updated patch based on comments

// Each is available only if >>appripriate<< for the object.
small typo

+const __cz_guid      = "59c81df5-4b7a-477b-912d-4e0fdf64e5f2";

What's that for?

r=rginda

Comment 13

[James Ross]

That's ChatZilla's GUID, and isn't nessessary for this change but I used it in
another patch I'm working on (including the icons in the XPI) and thought it
would be nice to put in there.

Comment 14

[James Ross]

Checked in.