-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Glen, but would add another wrinkle. Let's make a decision and stick to it!!! Now, who wants to start a VOTE? :)
- -- dims Glen Daniels wrote: | Hi Ruwan: | | If a given transport really only has relevance in the Synapse | environment, then of course that transport has no need to exist outside | Synapse. But if a transport is generically useful, I'd prefer to see it | somewhere in WS space as opposed to specifically within Synapse. And if | some generic transport needs tweaking in particular ways for Synapse, | then those ways should be exposed as configuration or plug-points on the | transport, which get exercised by Synapse (but also tested in the | transport build). Example - the nhttp transport could just include a | callback property which, if set, passes the 202 to a listener and | ignores it otherwise (perhaps that's exactly the way it works). In the | SMTP case, we should discuss what happens, but again I don't see any | issue with making a clean and useful general SMTP transport - why should | there need to be two of them?? | | Here's my use case. Someone wants to use nhttp, or JMS, or SMTP, with | Axis2. They're not a Synapse user and are not interested in downloading | Synapse. I want to make sure that this user can easily locate, | download, and install the transport they want. At the same time I want | the Axis2 and the Synapse communities both sharing their skills to make | the best set of transports available for Axis2 and of course Axis2+Synapse. | | I'm not wedded to the details, as long as we can make that happen. It | seems to me right now that ws-commons/transports is a better way to do | this than having lots of extension transports in Synapse, but I'm | willing to be convinced otherwise. | | Thanks, | --Glen | | Ruwan Linton wrote: |> I forgot to mention that, of cause one can use these transports with |> knowing the limitations and issues of those, when working directly |> with axis2 |> |> Thanks, |> Ruwan |> |> On Tue, Apr 22, 2008 at 11:16 PM, Ruwan Linton <[EMAIL PROTECTED] |> <mailto:[EMAIL PROTECTED]>> wrote: |> |> Hi Dims, Glen and all, |> |> On Tue, Apr 22, 2008 at 10:48 PM, Davanum Srinivas |> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: |> | Glen, | | At this point, Can we please agree that it's better for the | people who actually work on it have their way :) | | |>> +1 for this idea ... and one more thing is that; | |>> Although the transports which resides under synapse code base are |>> just axis2 transports, there are some special cases that synapse |>> needs from its transports. For example; | | * nhttp transport requires 202 Accepted HTTP messages to be | injected inside to synapse so that it can complete mediation | of one-way messages as well as we need those messages to be | injected on the separateListener case, where as axis2 should | just neglect those HTTP messages. | * Same with 500 Internal Server Error on nhttp | * smtp transport requires to treat all the Cc headers and Cc the | message to all the specified addresses (we have discussed this | earlier on axis2 and this is wrong according to the WS-MEPs, | because there are many outs) | |>> There are a number of synapse specific logic inside synapse |>> transports, because synapse is not purely bound to WS space, but it |>> is a mediation framework (ESB) which should support most of the |>> other scenarios going out of the WS space. There for these |>> transports may not directly work with axis2 and it is not at all a |>> good idea to move them out from synapse code base. | |>> Thanks, |>> Ruwan |>> | | | thanks, | dims | | | Glen Daniels wrote: | | Asankha C. Perera wrote: | |> Dims | |>> - there should not be stale copies | |>> - people who work on them should work where they want to. | |> +1 to both! | | | | Agreed - I'd just prefer people wanted to work on them under | WS/Axis. :) | | | |> I'd like to maintain these under Synapse.. We wrote these | transports | |> primarily for use by Synapse, and now we have JMS, | NIO-HTTP/S, Mail, | |> VFS (File), FIX and AMQP already.. These belong to a separate | Maven | |> module thats published to the Apache snapshots and Maven |>> Central | |> repos, and | | | | Hm. So this is a bit of a separate conversation, but *each* | of the | | transports should be its own deployable artifact. If I want | the AMQP | | transport for some work I'm doing, I don't want to bother | downloading | | all the others.... Wherever they end up we should fix that!! | | | |> this JAR does not depend on the Synapse codebase at all. | Anyone who | |> wishes to use these can do so without any problems | whatsoever, and | |> raise JIRA's for bugs/enhancements where the code is actually | maintained. | | | | Yeah. I just think this makes a lot more sense under WS. | | | |>> | | These transports (JMS, NIO, whatever) are going to be | generally | |>> useful to any Axis2 user, so why make them go look in |>> Synapse's | |>> codebase for them? | |> I agree,.. however these transports were written by the |>> Synapse | |> community for primary use by them. So instead of asking |>> them to | |> maintain the code they write somewhere else - for the | convenience of | |> the secondary users, why not clearly document the available | options | |> under Axis2 and where one could download these extension | transports | |> developed by the Synapse community? | | | | Sure, I'm not saying that wouldn't work - what's really | important to me | | is that Axis2 users get a clear picture of the available | transports when | | they download Axis2 and use our website. This is both to avoid | | duplication of effort and to enable users to use the richest | set of | | components available. It seems to me that the most natural |>> way to | | achieve this is to contribute new transports to ws-commons or | Axis2. | | | | Also consider this - wouldn't it be cool to be able to run the | Axis2 | | test suite (which is presumably much more comprehensive than | Synapse's | | testing of Axis2) over each of the transports that Synapse | originally | | built? I would think that might demonstrate some issues that | Synapse | | itself might not find, thus enabling the transports to be | improved. | | | | But if the community wants to keep developing these under | Synapse, then | | we definitely need some pointers in the Axis2 code and web | pages, and | | those pointers need to be maintained. | | | | Thanks, | | --Glen | | | | | |>> --------------------------------------------------------------------- | | To unsubscribe, e-mail: [EMAIL PROTECTED] | <mailto:[EMAIL PROTECTED]> | | For additional commands, e-mail: [EMAIL PROTECTED] | <mailto:[EMAIL PROTECTED]> | | |> |> |> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> |> |> |> |> |> -- Ruwan Linton |> http://www.wso2.org - "Oxygenating the Web Services Platform" |> |> |> |> -- |> Ruwan Linton |> http://www.wso2.org - "Oxygenating the Web Services Platform" | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIDiy9gNg6eWEDv1kRAkj7AKC7o3dhpnCmS5Pxjo23O/1McEqzeQCgyD0B +BQwhpVIwIT+EjQ/vCS9G1Y= =EzIW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
