[Embedlets-dev] Re: CVS Code tree

[Andrzej J. T. <an...@ch...>]

Brill says:

> I think you'll start getting feedback when we start to actually try to
> implement test cases... I have the same problem with Cork, where I don't get
> much feedback, so I don't know if the system is working for anyone ;)

I hear ya....bit of a chicken and egg, but with the stuff I have done, we 
have the spec (embedlets), the container RI (outpost) and the sample app 
(outhouse), so there is a lot to look at and review.  The design of the 
embedlet API's is especially critical.

> As soon as I can get a good tagged source tree I'll start creating test
> cases built on top of Cork, with some device access... but I want to know what
> changes (and how) before I start having to replace my source tree on every
> update.

No problem....it won't be too long.

How about this for a temporary solution......I'll post full 
source/distribution trees to CVS sooner (ie. this weekend), rather than 
later.  

However, I think to keep a handle on things and to minimize the impact on 
other people's work, we should allocate some responsibilities as to who 
"owns" certain pieces.  The part I'm most worried about is churn in the 
Embedlet Core Interfaces and Outpost Core Services, which would have 
widespread impact if the changes are not managed.

It seems we have already stratified to a great degree, with you on JAPL, Ted 
taking the Graphical Wiring (hey Ted....the current Outpost RI has enough 
dynamic capability that you can already start thinking/working on this!), me 
on Core (embedlet spec and core Outpost RI services), Chris is very 
interested in the Persistence Service and Gregg is interested in doing a Mesh 
inter-system communications service.  If we keep this responsibility 
structure for the moment it will allow us to go forward quickly with a 
minimum of disruptive impact.

Does this make sense?

> be careful with Jalopy.. I integrated it into the cork build a little while
> ago, but found it caused more problems with my source tree than it was worth,
> so instead I have it set up so I can manually format a particular source file
> when I'm working on it. If your going to set up it, I suggest you only do it
> with an automated CVS commit, and only just before the commit takes place (and
> only the files that have changed!) otherwise you get Jalopy resetting all the
> files changed or not, and CVS thinks they have changed.

I was thinking about those issues....and will see what I can do about them.

> Ok, lets check it in, tag it, and we can branch it later if we need to.... I
> also suggest a separate branch (or module) for my japl integration, as I don't
> know yet just from looking what I will have to do.

Make JAPL a separate module.  Since I've been keeping everything decoupled 
and separated, I will create three modules for my source trees, one each for 
Embedlets, Outpost and Outhouse.

> heh... Yah, the age old problem... I find it easier to do brief
> documentation, get something working, and go back and document, then do the
> next chunk... the long and short is that no matter how much you pre-design
> something, you can never actually know its right until you get down to brass
> tacks, and make it work.

I agree...which is why I went on the spree bouncing back and forth between 
the spec (embedlets) the RI (outpost) and a test app (outhouse) since it was 
faster to do this with only one person.  But now there is a lot of "meat" in 
place....and so it needs some peer review.  It's not like the code base is 
just interfaces, since there is a lot of implementation stuff behind it 
already.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com