Search found 147 matches

by Kellanved
Sat May 01, 2010 11:31 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Accepted] Avatar improvements, Gravatar
Replies: 15
Views: 32209

Re: [RFC] Avatar improvements, Gravatar

Posts, being stored in the database are utterly outside of this RFC. You can place your database in the cloud just fine - even with 3.0.
by Kellanved
Tue Apr 27, 2010 7:38 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Accepted] Avatar improvements, Gravatar
Replies: 15
Views: 32209

Re: [RFC] Avatar improvements, Gravatar

Actually, it would be a different RFC. We have: -Storing files outside the root -> should be a feature of the storage API for uploads -storage API - RFC forthcoming, although it'll be a lot like cache -new avatar types/delivery options - should be handled by proposing hooks to alter/add avatar optio...
by Kellanved
Mon Apr 26, 2010 10:13 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Merged] General Hook Architecture of phpBB3.1
Replies: 121
Views: 129889

Re: General Hook Architecture of phpBB3.1

The actual hooks will be defined in their own RFC phase, the list is more an example than an actual compilation. The template-part can be found here: http://area51.phpbb.com/phpBB/viewtopic.php?f=84&t=32796 I agree that there should be some style-dependent override; a strict solution would be to jus...
by Kellanved
Sun Apr 25, 2010 10:06 am
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Accepted] Avatar improvements, Gravatar
Replies: 15
Views: 32209

Re: [RFC] Avatar improvements, Gravatar

Adding a new avatar type and abstracting from the storage of files are two different issues. Storage abstraction is something we have to consider, but it wouldn't be limited to avatars. On the other hand, introducing other avatar types might be easier to do by providing the appropriate hooks.
by Kellanved
Sat Apr 24, 2010 5:33 pm
Forum: [3.x][Archive] RFCs
Topic: [feature/mass-email-speed-control]
Replies: 20
Views: 16075

Re: [feature/mass-email-speed-control]

I would prefer to get rid of file-based locking alltogether; the cache or database layers are far more promising. The problem - actually a downright showstopper - with file-based locking is that it is not feasible for multi-server and cloud installs.
by Kellanved
Mon Apr 19, 2010 11:39 am
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Merged] General Hook Architecture of phpBB3.1
Replies: 121
Views: 129889

Re: General Hook Architecture of phpBB3.1

I don't know how else I can convey this to you, but what should be and what is are two different things. Core will change and break modifications. People will run old versions for a nontrivial amount of time. People do update their modified boards in pieces. This is the reality that you are ignorin...
by Kellanved
Sun Apr 18, 2010 5:04 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Merged] General Hook Architecture of phpBB3.1
Replies: 121
Views: 129889

Re: General Hook Architecture of phpBB3.1

Those are the caps I'm referring to. There is no reason to have more than one capital letter sequentially. This is rather particular; I don't see a problem with having a capital-letter convention for three interface methods. However, as discussed above, this will change. The fact is that a simple p...
by Kellanved
Sun Apr 18, 2010 3:10 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Merged] General Hook Architecture of phpBB3.1
Replies: 121
Views: 129889

Re: General Hook Architecture of phpBB3.1

Please go easy on the use of all caps. They are painful to type. Function names do not need capital letters at all. Remember also that php is case insensitive for function names. I am not aware of an "all caps". The caps used in the example are mostly placeholders for names; the MOD_ prefix (subjec...
by Kellanved
Sun Apr 18, 2010 2:05 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC|Merged] General Hook Architecture of phpBB3.1
Replies: 121
Views: 129889

Re: General Hook Architecture of phpBB3.1

Technically we can do without static methods - the idea is to avoid creating unneeded instances. I'm well aware of the definition of a callable, but a callable is not a priority. We need a priority value, not a callable. Again: The callable wouldn't help us in either case, as we need the priority va...