synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soumadeep" <>
Subject RE: [Synapse]RE: CryptoFactory:
Date Wed, 22 Mar 2006 06:18:47 GMT

Please see my comments inline

Best regards

-----Original Message-----
From: Sanjiva Weerawarana []
Sent: Wednesday, March 22, 2006 11:18 AM
Cc: Ruchith Fernando
Subject: RE: [Synapse]RE: CryptoFactory:

On Wed, 2006-03-22 at 09:43 +0530, Soumadeep wrote:
> Sanjiva,
> 1) First of all let me emphasize that Mukund's statement and my response
> Ruchith are no way related.


> 2) We work on the mediators and do a primary test before we commit it to
> ASF repository.

That is not a good model for development in ASF long term; ASF is about
open development as well, not just about releasing software under the
Apache license. It is a viable model for bootstrap, but now that we have
bootstrapped, we must do all the work here.
[Soumadeep]  Yes, I completely agree and that's why I added these points in
my earlier email
2) We work on the mediators and do a primary test before we commit it to the
ASF repository.
3) And whatever that we proposed (like Mukund's management related code
base or SynapseObject) are in the scratch already
4) The reason some of the mediators that we came up with didn't make it to
the repo yet is because of issues pertaining to data sharing between
mediators, and  you are aware of the long thread about SynapseObject per se.

One more thing that I would like to emphasize here is that I do agree that
all the development should happen in the repo, but from a realistic stand
point as you may agree one can't keep writing a line of code and keep
committing it but surely the scratch area should be fine. And I reiterate
that we have no intention of putting mediators in one go but put a generic
structure to it and then let the community develop it. One can argue
endlessly on this but then just to put it in the right perspective we have
developed these features and have gone through several use cases with many
customers in a rigorous manner. Hence, apart from just the code we are also
sharing the knowledgebase so that we don't start re-inventing the wheel
again but maybe add to it. On a lighter note maybe add some good tiers to it

Of course *it is perfectly viable* for Infravio or anyone else to build
their own add-ons and ship them in their products.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message