Conal,
To continue our discussion publically and hopefully get some input
from the cocoon developers...
I think that putting all the functionality of logging into a server,
retreiving messages and folders, and turning that data into XML is a
little too much for a Source. If you have to pass parameters to the
generator to specify servers and passwords, etc.. then why not just make
a MailGenerator?
There just seems to be too much 'logic' to be performed that has
nothing to do with actually outputting the XML. Most mail systems won't
make a new connection to the server to retrieve each individual message.
They usually download them all at once into a local store. Will the
source be responsible for this? If you're just concerned with viewing
messages and don't want to store them, then you might want to keep the
connection open so you don't have to reconnect for each message. In this
case you'd want to store the JavaMail connection in the session, and I'm
not aware the a source has access to the session.
Who knows, maybe this is a better job for an action or flowscript in
conjunction with a MailSource, but I don't think a source should do it
all.
just my $.02
Justin
On Friday, August 2, 2002, at 04:34 PM, Conal Tuohy wrote:
>>>> Context is one per application, Configuration and Parameters
>>>> are one per
>>>> Source type (in your case - one configuration per all instances of
>>>> MailSource).
>
>>> Just to get this clear though - if my Source was a Generator instead,
>>> could I pass parameters to it on a per-pipeline basis, just by
>>> implementing Parameterizable?
>>
>> Yes.
>>
>> Vadim
>
> OK. But why CAN'T I do this with a Source? [Thinking aloud] The
> Generator is
> the container for my Source isn't it? Presumably the Generator should
> Parameterize my Source when it resolves it (or Reparameterize it), so
> couldn't my Source access the parameters passed to the Generator, in the
> example below? Perhaps the parameter names should be "mail:username" and
> "mail:password" so they don't clash with parameters the Generator might
> be
> expecting.
>
>>> e.g.
>>>
>>> <map:match pattern="mail/*/*/*">
>>> <map:generate type="mail" src="{1}">
>>> <map:parameter name="username" value="{2}">
>>> <map:parameter name="password" value="{3}">
>>> </map:generate>
>>> etc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
