plone

zope.sendmail-4.0.1-2.lbn25.noarch
zope.sendmail is a package for email sending from Zope 3 applications. Email sending from Zope 3 applications works as follows: A Zope 3 application locates a mail delivery utility (IMailDelivery) and feeds a message to it. It gets back a unique message ID so it can keep track of the message by subscribing to IMailEvent events. The utility registers with the transaction system to make sure the message is only sent when the transaction commits successfully. (Among other things this avoids duplicate messages on ConflictErrors.) If the delivery utility is a IQueuedMailDelivery, it puts the message into a queue (a Maildir mailbox in the file system). A separate process or thread (IMailQueueProcessor) watches the queue and delivers messages asynchronously. Since the queue is located in the file system, it survives Zope restarts or crashes and the mail is not lost. The queue processor can implement batching to keep the server load low. If the delivery utility is a IDirectMailDelivery, it delivers messages synchronously during the transaction commit. This is not a very good idea, as it makes the user wait. Note that transaction commits must not fail, but that is not a problem, because mail delivery problems dispatch an event instead of raising an exception. However, there is a problem – sending events causes unknown code to be executed during the transaction commit phase. There should be a way to start a new transaction for event processing after this one is commited. An IMailQueueProcessor or IDirectMailDelivery actually delivers the messages by using a mailer (IMailer) component that encapsulates the delivery process. There currently is only one mailer: ISMTPMailer sends all messages to a relay host using SMTP.
Located in LBN / … / Plone and Zope / BastionLinux 25
zope.sendmail-4.0.1-2.lbn25.noarch
zope.sendmail is a package for email sending from Zope 3 applications. Email sending from Zope 3 applications works as follows: A Zope 3 application locates a mail delivery utility (IMailDelivery) and feeds a message to it. It gets back a unique message ID so it can keep track of the message by subscribing to IMailEvent events. The utility registers with the transaction system to make sure the message is only sent when the transaction commits successfully. (Among other things this avoids duplicate messages on ConflictErrors.) If the delivery utility is a IQueuedMailDelivery, it puts the message into a queue (a Maildir mailbox in the file system). A separate process or thread (IMailQueueProcessor) watches the queue and delivers messages asynchronously. Since the queue is located in the file system, it survives Zope restarts or crashes and the mail is not lost. The queue processor can implement batching to keep the server load low. If the delivery utility is a IDirectMailDelivery, it delivers messages synchronously during the transaction commit. This is not a very good idea, as it makes the user wait. Note that transaction commits must not fail, but that is not a problem, because mail delivery problems dispatch an event instead of raising an exception. However, there is a problem – sending events causes unknown code to be executed during the transaction commit phase. There should be a way to start a new transaction for event processing after this one is commited. An IMailQueueProcessor or IDirectMailDelivery actually delivers the messages by using a mailer (IMailer) component that encapsulates the delivery process. There currently is only one mailer: ISMTPMailer sends all messages to a relay host using SMTP.
Located in LBN / … / Plone and Zope / BastionLinux 19
zope.sequencesort-3.4.0-4.lbn13.noarch
zope.sequencesort
Located in LBN / … / Plone and Zope / BastionLinux 13
zope.sequencesort-4.0.1-1.lbn25.noarch
This package provides support for sorting sequences based on multiple keys, including locale-based comparisons and per-key directions.
Located in LBN / … / Plone and Zope / BastionLinux 25
zope.sequencesort-4.0.1-1.lbn25.noarch
This package provides support for sorting sequences based on multiple keys, including locale-based comparisons and per-key directions.
Located in LBN / … / Plone and Zope / BastionLinux 19
zope.server-3.6.3-2.lbn13.noarch
zope.server
Located in LBN / … / Plone and Zope / BastionLinux 13
zope.server-3.9.0-1.lbn25.noarch
This package contains generic base classes for channel-based servers, the servers themselves and helper objects, such as tasks and requests.
Located in LBN / … / Plone and Zope / BastionLinux 25
zope.server-3.9.0-1.lbn25.noarch
This package contains generic base classes for channel-based servers, the servers themselves and helper objects, such as tasks and requests.
Located in LBN / … / Plone and Zope / BastionLinux 19
zope.session-3.9.5-2.lbn13.noarch
zope.session
Located in LBN / … / Plone and Zope / BastionLinux 13
zope.session-4.1.0-2.lbn25.noarch
Sessions provide a way to temporarily associate information with a client without requiring the authentication of a principal. We associate an identifier with a particular client. Whenever we get a request from that client, we compute the identifier and use the identifier to look up associated information, which is stored on the server. A major disadvantage of sessions is that they require management of information on the server. This can have major implications for scalability. It is possible for a framework to make use of session data very easy for the developer. This is great if scalability is not an issue, otherwise, it is a booby trap.
Located in LBN / … / Plone and Zope / BastionLinux 25

« Previous 10 items Next 10 items » 1 ... 4855 4856 4857 4858 4859 4860 4861 ... 4868

Sections

Search results


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.