Re: IRC
Reply #16 –
(01:47:17 AM) emanuele: Spuds> But if you looks at Ema's neked pictures you may go blind :P
(01:47:36 AM) emanuele: That's why I don't have any recent picture! :P
(01:48:24 AM) Norv: Heh. You send them through phpbb only, huh?
(01:49:04 AM) emanuele: I checked that because I still have my old site here... :P
(01:50:13 AM) ***Norv tries to change my own perspective about it, but I'm not convinced...
(01:51:38 AM) emanuele: So you Norv don't like "private" attachments?
(01:52:54 AM) emanuele: And Spuds?
(01:55:31 AM) ***Norv is not sure. It's like the IPs issue... of which I didn't tell you about. I wonder if we can/want to add an option for a 'private' login, for which no IPs are logged for the user. Similarly, perhaps we can exclude from maintainance screens some attachments.
(01:57:09 AM) Spuds: Just seems like something that I see asked for often enough ... we could also add some basic file crypt to pm attachments ... makes the admin open the db, get the key, etc etc if we wanted it more ummm agrivating to get at the file
(01:57:48 AM) Spuds: or even aggravating :D
(01:58:48 AM) Spuds: No IP logging .. now that is crazy talk
(02:06:28 AM) emanuele: time to go, bye!
(02:06:31 AM) Norv: Every now and then, I saw (very rarely) a request for disabling any IP logging, at least for members. The point being particular needs of private forums, whose admins wanted to assure their members they have privacy to the level of no IP tracking. I'm not joking. Even though this isn't the problem of the server software, it's up to the client to make that choice, but.
(02:06:46 AM) Norv: nighty
(02:10:28 AM) emanuele: I think you just need to change a couple of lines for that, should be a pretty simple mod
(02:10:38 AM) emanuele: I think SpiderCheck is in the wrong file...
(02:10:56 AM) emanuele: (or addon)
(02:11:43 AM) emanuele left the room (quit: Remote host closed the connection).
(02:15:51 AM) Norv: for members-only, you mean?
(02:47:56 AM) Norv: Bah. SpiderCheck() is out. :D
Re: IRC
Reply #18 –
(12:36:57 AM) emanuele: and the current system is not very well thought to stay in-synch
(12:37:47 AM) emanuele: the documentation will always be up-to-date, but old releases will point to the newer documentation
(12:38:01 AM) emanuele: (for any possible language of course)
(12:39:26 AM) Norv: True, but for user level (and newbie) documentation, I'm not sure it should change that much between major versions. It shouldn't (in theory).
(12:40:51 AM) Norv: Which pretty much cancels the previous point, heh. SMF 2.0 did change, but SMF 2.0 has been a major version and well worth that name.
(12:41:18 AM) Norv: Arguably.
(12:45:19 AM) emanuele: the documentation at that point doesn't make any distinction between minor and major versions, I'm just saying we should consider to separate the (user?) documentation for the different versions
(12:45:44 AM) emanuele: if there are things that are similar it should be pretty easy to clone the page and continue from there
(12:47:06 AM) emanuele: documentation is a pain... XD
(12:52:25 AM) Norv: fair enough
(12:53:22 AM) Norv: I still don't see what the best solution is, for 1.0 and beyond.
(12:55:58 AM) Norv: If we keep wiki links: you can't have a single link (can you?) to a wiki, it's still better to have the subjects broken down to redirect the user to the items more likely of interest...
(12:57:08 AM) Norv: If we (re)add packaged documentation: admin documentation can go in /docs, user documentation has to be a page(s)
(01:02:34 AM) Norv: I mean, in /docs we can add other separate files, if there's something more useful, simply available. (I'd think at a SSI/API introduction, for example; or how to use admin features, such as maintainance; or for a cli script if we add that clearly - i.e. upgrade is already, could have more).
(01:03:24 AM) emanuele: yeah, probably: (wiki|docs)/1.0/page