rcube_user::create)?
$data = $rcmail->plugins->exec_hook('create_user', array('user'=>$user, 'user_name'=>$user_name, 'user_email'=>$user_email));
Do you plan to add possibility to stop function execution after executing a hook inside of it?
'data' => $message->get_part_content($pid),
I think attachments could and should be handled via file pointer.
On Thu, May 14, 2009 at 17:59, A.L.E.C alec@alec.pl wrote:
- Shouldn't 'create_identity' hook be called after 'create_user' (in
rcube_user::create)?
You're probably right about this. I'll check that.
- E.g. in rcube_user::create() we have:
$data = $rcmail->plugins->exec_hook('create_user', array('user'=>$user, 'user_name'=>$user_name, 'user_email'=>$user_email));
Do you plan to add possibility to stop function execution after executing a hook inside of it?
Actually hooks can return 'abort' => true which will stop further handlers to be executed and - if the applications supports it - also abort the whole operation. In this case this could be implemented, yes.
- In mail/compose.inc we have now in rcmail_save_attachment function:
'data' => $message->get_part_content($pid),
I think attachments could and should be handled via file pointer.
Not necessarily. For example the db-based file handler needs the file contents in memory to pass them to the database. Using a file for temporary storage just slows down the operation because disk access is needed.
To get best of both worlds, we could create another hook like 'open_filew' which can be called before 'save_attachment' and will return a file pointer, in case the plugin works with files. The 'save_attachment' hook will then pass the file pointer in the 'data' field. If the 'open_filew' hook doesn't return a file pointer, we keep the current way of passing the file contents as 'data'.
What do you think about this?
Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
I think attachments could and should be handled via file pointer.
Not necessarily. For example the db-based file handler needs the file contents in memory to pass them to the database. Using a file for temporary storage just slows down the operation because disk access is needed.
Right, but imagine forwarding mail with 100MB attachment. You need it to be loaded into memory, not good.
To get best of both worlds, we could create another hook like 'open_filew' which can be called before 'save_attachment' and will return a file pointer, in case the plugin works with files. The 'save_attachment' hook will then pass the file pointer in the 'data' field. If the 'open_filew' hook doesn't return a file pointer, we keep the current way of passing the file contents as 'data'.
What do you think about this?
Second option, since we have attachments handler plugin in requirements, is to use config variable for that.
A.L.E.C wrote:
Thomas Bruederli wrote:
I think attachments could and should be handled via file pointer.
Not necessarily. For example the db-based file handler needs the file contents in memory to pass them to the database. Using a file for temporary storage just slows down the operation because disk access is needed.
Right, but imagine forwarding mail with 100MB attachment. You need it to be loaded into memory, not good.
For sending you'll need that anyway...
To get best of both worlds, we could create another hook like 'open_filew' which can be called before 'save_attachment' and will return a file pointer, in case the plugin works with files. The 'save_attachment' hook will then pass the file pointer in the 'data' field. If the 'open_filew' hook doesn't return a file pointer, we keep the current way of passing the file contents as 'data'.
What do you think about this?
Second option, since we have attachments handler plugin in requirements, is to use config variable for that.
I don't understand. What do you want to configure about this?
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
To get best of both worlds, we could create another hook like 'open_filew' which can be called before 'save_attachment' and will return a file pointer, in case the plugin works with files. The 'save_attachment' hook will then pass the file pointer in the 'data' field. If the 'open_filew' hook doesn't return a file pointer, we keep the current way of passing the file contents as 'data'.
What do you think about this?
Second option, since we have attachments handler plugin in requirements, is to use config variable for that.
I don't understand. What do you want to configure about this?
Because both plugins could handle both methods of file handling. So, we don't need another plugin, but just an option.