Hi Bongjae
I sent you a separate email in response to your private email for the
branch related question. More below:
Bongjae Chang wrote:
> Hi Shreedhar.
> /Wrote Shreedhar:/
> />However, I think it would be perfectly okay for you to open up a
> branch and do this experimentation and come back with results.
> /
> I am very pleased at your affirmative reply. If I am able toopen up a
> branch and try to proceed to this experimental issue earlier before
> Shoal 2.0 release, I thinkthat it would be a good chance to both me
> and the next Shoal version. Could you tell me how to open the branch?
Another Example in addition to one I sent in separate email :
http://www.netbeans.org/community/sources/branches.html
> //
> //
> /
> /Wrote Shreedhar:/
> /
> />I think Jim Marino had expressed interest in abstracting out the
> transport layer etc. for pluggability and it may be advantageous to
> learn from this experience through such a collaboration. /
> Iwas glad to seeJim Marino's opinions about abstracting out the
> transport layer from use mailing. If I could do this experimentation
> in collaboration with Jim Marino, or I could call in Jim Marino'said
> at least, it wouldalso be a good opportunity to me.
Sure. Jim is on the users list so feel free to ask.
> Thanks.
> --
> Bongjae Chang
>
> ----- Original Message -----
> *From:* Shreedhar Ganapathy <mailto:Shreedhar.Ganapathy_at_Sun.COM>
> *To:* dev_at_shoal.dev.java.net <mailto:dev_at_shoal.dev.java.net>
> *Cc:* Mahesh Kannan <mailto:Mahesh.Kannan_at_Sun.COM>
> *Sent:* Friday, April 17, 2009 9:25 AM
> *Subject:* Re: [Shoal-Dev] About an improvement of JXTA dependency
>
> Hi Bongjae
> Hope you are doing well. Some responses below :
>
> Bongjae Chang wrote:
>> Hi.
>> I know that the Group Communication Provider API provides for
>> integration of any group communication technology and current
>> Shoal's SPI Implis JXTA.
> At least that was our intention :)
>> Iam interested in alternatingJXTA group communication module
>> recently, so I am trying to review SPI Impl for JXTA.
> That is very interesting as it would also test the adequacy of the
> Shoal Provider SPI.
>> Actually, I would like tobe trying to apply a SPI impl forour
>> network layer which is our company's network module in Web
>> Application Server(JEUS) to Shoal without JXTA experimentally.
>> Shoal has twofollowing packageswhich are dependent on JXTA as you
>> know.
>> - com.sun.enterprise.ee.cms.impl.jxta.*
>> - com.sun.enterprise.jxtamgmt.*
>> When I reviewedpackages and classes which were concerned with
>> JXTA, I thoughtmost ofabove classes and algorithms could be reused.
>> I think that ClusterManager, ClusterViewManager, MasterNode,
>> HealthMonitor, ViewWindows, MessageWindows,
>> DistributedStateCacheImpland other classes(etc...)whichare
>> dependent on JXTA in above packages already play an important
>> part in Shoal.
> If I remember correctly, the SPI impl, DistributedStateCacheImpl,
> ViewWindow, MessageWindow, etc. (i.e most of the classes in
> com.sun.enterprise.ee.cms.impl.jxta ) should be independent of Jxta.
>
> The com.sun.enterprise.jxtamgmt.* classes are what we call
> Provider library classes that should technically be compile time
> independent of the other classes (but is currently not so due to
> direct instantiation of some classes).
>
>> SoI would like tomake the best use of above packages' classes if
>> possible.
>> For example,
>> - If SystemAdvertisementis not a class but a interface andinteger
>> ID replaces net.jxta.id.ID as unique ID, all
>> com.sun.enterprise.ee.cms.impl.jxta.* classes can be reused
>> without JXTA.
> Conceivably, yes.
>> -If Shoal has own additional APIs and interfaceslike
>> net.jxta.endpoint.Message, sender API and
>> net.jxta.pipe.PipeMsgListener forreceiver API,
>> com.sun.enterprise.jxtamgmt.* canbe resued as well. Then, most of
>> algorithms can be recycled such as master's discovery and
>> selection algorithm.
> That is also true to a large extent.
>> So, I am curious to know that you are making more plans for
>> integration of any group communication module like abstracting
>> and reusing above modules and eliminating JXTA's dependency.
>> And I would like to know an outline such as a future schedule for
>> more abstractions of the communication layer if you are planning.
> We do not have plans for this area for the medium term future
> until say, mid 2010 due to Sailfin v2 and GlassFish v3.1 Roadmap
> commitments which require us to be far more stable and reliable
> earlier than later. In fact, we will mostly be focused on fine
> tuning what is currently there for correctness, scalability,
> reliability and robustness.
>
> However, I think it would be perfectly okay for you to open up a
> branch and do this experimentation and come back with results.
> I think Jim Marino had expressed interest in abstracting out the
> transport layer etc. for pluggability and it may be advantageous
> to learn from this experience through such a collaboration.
>
>> ex) whether glassfish V3 will be able toinclude new Shoal version
>> which can support any group communication module like JGroup or not.
> We do have plans for a Shoal 2.0 release in the mid 2010 timeframe
> that is more focused on the lines of providing features like a
> robust highly scalable distributed cache, cluster wide singleton
> services etc. We are working on that roadmap which we will put out
> for community comments and suggestions in the coming weeks.
>
> Cheers
> Shreedhar
>
>> Thanks.
>> --
>> Bongjae Chang
>