Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tm-dev] RE: RSE Refactorings

Hi Kushal,

feel free to check in your refactorings till tuesday evening.

We'll discuss things in the committer meeting on wednesday 
morning. The plan is to only do bug fixing from wednesday
till friday and release M4 friday night.

If it turns out that we'll need more time for some important
API changes, we might loosen that schedule. But I would not
like to do that. 

Also note that although M4 is official API freeze, this
just means that we'll need to do a voting on all commiters
before more api changes are allowed -- so it'll not be
impossible but much harder to do.

Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm 

> -----Original Message-----
> From: Kushal Munir [mailto:kmunir@xxxxxxxxxx] 
> Sent: Friday, August 11, 2006 11:47 PM
> To: Oberhuber, Martin
> Subject: RE: RSE Refactorings
> 
> Hi Martin,
> 
> I wasn't able to get much done this week as I only returned 
> to work late
> yesterday. Originally I expected to hit API freeze by end of 
> this week, but
> the refactoring work has also taken a little longer than 
> expected. It looks
> like the RSE persistence provider will also have to move to core.
> Otherwise, we can not do effective core vs ui separation of RSE model
> objects. I'm sorry I wasn't able to communicate this earlier. 
> I've checked
> in much of the refactoring work already, but the rest won't 
> be completed
> until Tuesday morning (probably end of Monday). Let me know 
> if this is ok.
> I'll hold off making any changes until then.
> 
> The refactoring work is somewhat open ended. I still see many 
> classes in
> RSE that I don't think we have reviewed. There are classes 
> that I think
> should probably be in internal packages. There are also methods that
> probably should not have the level of visibility that they 
> have. I think
> we'll all need to engage in a fair amount of code review and 
> make these
> changes to provide a compact, polished API set. However, given the
> timeframe I don't think we'll be able to make many of these 
> changes until
> V2. So we may have to make "API" changes in V2, however minor 
> they may be,
> and I think it's good that we're marking our API set 
> provisional in V1.
> 
> Cheers,
> 
> Kushal Munir
> Websphere Development Studio Client for iSeries
> IBM Toronto Lab, 8200 Warden Ave., Markham, ON
> Phone: (905) 413-3118        Tie-Line: 969-3118
> Email: kmunir@xxxxxxxxxx
> 
> 
> 
>                                                               
>              
>              "Oberhuber,                                      
>              
>              Martin"                                          
>              
>              <Martin.Oberhuber                                
>           To 
>              @windriver.com>           Kushal 
> Munir/Toronto/IBM@IBMCA      
>                                                               
>           cc 
>              08/11/2006 02:28                                 
>              
>              PM                                               
>      Subject 
>                                        RE: RSE Refactorings   
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> Hi Kushal,
> 
> My things can wait. I'm just collecting ideas here,
> most of which may well go into RSE 2.0. If you're
> moving stuff to core anyway, that'll probably make
> some things a lot easier.
> 
> What is the timeframe for your refactorings? Note
> that the official API freeze is TODAY.
> 
> It's extremely important that we communicate what
> we're up to right now. Let everybody know what you
> are planning, and when you want to have it finished.
> Better be conservative with the timing, but make
> sure that you can really deliver in the time frame.
> Otherwise we'll not be able to accept the changes
> for 1.0.
> 
> Note that there are external clients programming
> against our APIs, and they rely on getting something
> stable as per the project plan.
> 
> Thanks,
> --
> Martin Oberhuber
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
> 
> > -----Original Message-----
> > From: Kushal Munir [mailto:kmunir@xxxxxxxxxx]
> > Sent: Friday, August 11, 2006 8:07 PM
> > To: Oberhuber, Martin
> > Subject: Re: RSE Refactorings
> >
> > Hi Martin,
> >
> > Can you please let me know when you've made the changes
> > (depending on the
> > outcome of the discussions in the mailing list). The
> > refactoring work I'm
> > in the middle of consists of moving SubSystemConfiguration
> > extension point
> > to the org.eclipse.rse.core plugin. I've isolated a number 
> of changes
> > related to filters and they've already been refactored, but
> > I'm not able to
> > change things in isolation anymore so all the changes have to go in
> > together. This will impact the various model objects Subsystem,
> > SubsystemConfiguration, IHost, SystemFilter, etc.
> >
> > However, if you're planning on making these changes, would it
> > be better to
> > wait for you? If you're planning on making changes to the
> > extension point
> > such that we would have both a factory and configuration,
> > with the factory
> > being non-UI and configuration being dependent on the UI,
> > then that would
> > directly impact the core vs ui separation we're aiming for.
> > Please let me
> > know.
> >
> > Thanks,
> >
> > Kushal Munir
> > Websphere Development Studio Client for iSeries
> > IBM Toronto Lab, 8200 Warden Ave., Markham, ON
> > Phone: (905) 413-3118        Tie-Line: 969-3118
> > Email: kmunir@xxxxxxxxxx
> >
> >
> >
> >
> >              "Oberhuber,
> >
> >              Martin"
> >
> >              <Martin.Oberhuber
> >           To
> >              @windriver.com>           "David Dykstal"
> >
> >
> > <david_dykstal@xxxxxxxxxx>, David
> >              08/11/2006 09:47
> > McKnight/Toronto/IBM@IBMCA
> >              AM
> >           cc
> >                                        Kushal
> > Munir/Toronto/IBM@IBMCA,
> >                                        "Target Management
> > developer
> >                                        discussions"
> >
> >
> > <dsdp-tm-dev@xxxxxxxxxxx>
> >
> >      Subject
> >                                        RSE Refactorings
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hello Dave's,
> >
> > I would like to perform the following refactorings:
> >
> > 1. Rename Extension Point
> >       "subsystemconfiguration" --> "subSystemConfigurations"
> >    Rationale: Be more in-line with Platform names
> >
> > 2. Rename Extension Point Elements of "subSystemConfigurations"
> >    <configuration
> >       "class"       --> "factoryClass"       (required)
> >       "systemClass" --> "connectorService"   (optional)
> >    />
> >    Rationale: unify naming, and allow for further extension
> >    with e.g. serviceClass attribute or "class" attribute
> >    for an actual ISubSystemConfiguration.
> >
> > 3. Rename Classes and Interfaces
> >       *SubSystemConfiguration* --> *SubSystemFactory*
> >    Rationale: the SubSystemFactory is essentially a factory,
> >    since its main task is to create ISubSystem objects. Also,
> >    current RSE Documentation refers to "factories" in an
> >    endless number of places.
> >
> > 4. Move extension point documentation from plugin.xml
> >    into the *.exsd schema
> >
> > 5. Replace text matches in comments
> >       ISystem --> IConnectorService
> >
> >
> > We can think about adding more attributes to the
> > "subSystemConfigurations" extension point later,
> > allowing for a split between SubSystemFactory and
> > SubSystemConfiguration if desired.
> >
> > This would essentially mean adding a new type
> > ISubSystemConfiguration that would refer to
> > existing SubSystemFactories, in order to allow
> > better re-use of SubSystemFactories for work in
> > different configurations (services, connectorservices,
> > attributes).
> >
> > Would you agree with these refactorings?
> >
> > Thanks,
> > --
> > Martin Oberhuber
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
> 
> 
> 


Back to the top