RE: [Embedlets-dev] Re: CVS Code tree

[Christopher S. <cs...@oo...>]

Andrzej,

On the class hierachy:

Is there a reason you have not used interfaces as the starting point for the
abstract classes? This requires an extra class(interface) but it provides a
huge amount of flexibility if we need to substitute versions (full/lite) or
platform specific implementations later.

As you know it would be a simple level to add at the top:

iComponent
   ^
   :__ Component
           ^
           |____ Embedlet



Chris

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>