Thread: [Embedlets-dev] Re: CVS Code tree
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 19:42:16
|
Chris asks: > When are you going to post the full source tree to the Embedlets repository? > Until you do this it is impossible for anyone else to do any code development. > We will have no revision control until this is done as well. Soon.....in the meantime, the whole source tree is in the zip file.....so go look at it and get the feedback/discussions going! I see that as the next step, since it would be wise to review what currently exists before we go building much on top of it. I may be a decent developer, but I would not suggest that you accept the current stuff on face value alone, flattering though this might be. > I know that it is not your intention to code the complete project yourself! Nope....not enough time nor interest for that. ;-) > See my and Bill's post on the CVS repository. We cannot do anything with a zip > file, without risking overwriting our work. Sure you can...it's totally self contained so you can review it and provided feedback and discussion, which is what I think is needed before we start hammering out reams of new code/stuff. Not gonna post the code base in CVS (since I'm one version ahead) until the source code formatting (Jalopy) stuff is in place (coming soon) and I start to see some feedback from the group on the current stuff (up to you guys). Brill chimes in with a similar comment: > Would you mind posting the source to CVS rather and the zip files (in a > proper build environment)? Soon as I start to see some feedback on the current stuff. The core interfaces and design decisions need to be reviewed and agreed before we go helter skelter building on top of them. I also need to get the Jalopy source formatting in place first, to ensure that all checked in code is in line with the code conventions. > At the moment I've got ant set up to check out the zips, decompress them > into a build dir, etc... but you can't do any diffs, version checking, etc. on > the zip files ;) If you are willing, I will prepare a build env. for you using > the current zipped packages, which you can then modify (I have a bit of spare > time right now). No need, thanks....this is next on my list with the Jalopy stuff and is part way done already. Keep in mind, I posted these releases for DISCUSSION PURPOSES only....not to be used as the basis for further development (yet). My ideas on the interfaces, lifecycle and such are not necessarily the best or the be-all, so need to be reviewed. Besides, before you can start building on new stuff (optional services and the like) you need to understand what is already there, and how it works (eg. how to you structure an Embedlet Service), which should naturally lead to some discussion/review. Let's not get ahead of ourselves, in our rush to develop our favourite kewl component/addition. This first cut was just intended a proof of concept and a kick-start. It SHOULD NOT be accepted as is! Before we cast it in concrete (by building on top of the current interfaces too much, which will make it much harder to change the underlying contracts), let's make sure that they are as good as possible, 'cause to do anything else will compromise our plan to make Embedlets a defacto and distruptive standard that becomes widely adopted. The bane of many Open Source projects is the tendency to hack too much code too early, instead of doing documentation, design review and the like. We've got enough code now (too much probably, since I'm obviously not immune to the "let's sling more code" syndrome either ;-) ), and it's time to step back and ensure that we are going down the optimal path. So please go take a look at what's there....pick it apart...make suggestions....ask questions....critique the interfaces and design choices, as a first step. This shouldn't take long.....but the effort will pay off handsomely down the road. Then we'll be assured that the platform we are building on is optimal as we start to flesh out all the rest of the pieces that need doing (and there are many!). Soon as I get the Jalopy source reformatting tasks running to my satisfaction, I will populate the CVS "properly".....but please....in the meantime, start the review process! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 21:36:51
|
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 |
|
From: Christopher S. <cs...@oo...> - 2003-03-08 01:18:58
|
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
>
|
|
From: Nicola K. B. <nic...@ap...> - 2003-03-08 08:41:11
|
Andrzej Jan Taramina wrote, On 07/03/2003 22.36: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] ... >>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. Good :-) In OS CVS is the real scratchpad for all, like the mailing list is the discussion place. > 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. Testcases and discussions. You will see that people naturally get to work on certain parts, and decide that informally on the ML. It works well, and there is no "formal" need of assigning things, that maybe don't get followed for instant lack of time. For the "commmon" parts, testcases runing regularly via a cron job are the only real way of keeping things stable, also for when developers leave the group for any reason. I'd be happy to add this project to the ones run by Gump http://jakarta.apache.org/gump/ > 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? Hmmm, responsibility is of everybody to the same degree. If we keep things too separated, knowledge gets shared less... and the project starts depending too much on a single person. Yes, there are concern areas, and parts of code that some prefer, but as you have seen yourself, a natural layering has already occurred ;-) -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Brill P. <bri...@ro...> - 2003-03-07 20:12:56
|
Don't know if its just my system or not, but outpost_003.zip seems to be corrupt. Might want to check it. - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Brill P. <bri...@ro...> - 2003-03-07 20:18:00
|
> > See my and Bill's post on the CVS repository. We cannot do anything with a zip > > file, without risking overwriting our work. > > Sure you can...it's totally self contained so you can review it and provided > feedback and discussion, which is what I think is needed before we start > hammering out reams of new code/stuff. > > Not gonna post the code base in CVS (since I'm one version ahead) until the > source code formatting (Jalopy) stuff is in place (coming soon) and I start > to see some feedback from the group on the current stuff (up to you guys). Just tag the versions, so they can be reffered to. Thats what the tagging, and branching are for. > Brill chimes in with a similar comment: > > > Would you mind posting the source to CVS rather and the zip files (in a > > proper build environment)? > > Soon as I start to see some feedback on the current stuff. The core > interfaces and design decisions need to be reviewed and agreed before we go > helter skelter building on top of them. 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 ;) 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. > I also need to get the Jalopy source formatting in place first, to ensure > that all checked in code is in line with the code conventions. 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. Now... the problem with sourceforge is the darn SSH... I don't know if the ant CVS task can talk to the SSH'ed CVS or not. > Before we cast it in concrete (by building on top of the current interfaces > too much, which will make it much harder to change the underlying contracts), > let's make sure that they are as good as possible, 'cause to do anything else > will compromise our plan to make Embedlets a defacto and distruptive standard > that becomes widely adopted. 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. > The bane of many Open Source projects is the tendency to hack too much code > too early, instead of doing documentation, design review and the like. We've > got enough code now (too much probably, since I'm obviously not immune to the > "let's sling more code" syndrome either ;-) ), and it's time to step back and > ensure that we are going down the optimal path. 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. - Brill Pappin Rogue Robotics www.roguerobotics.com |
Thanks for helping keep SourceForge clean.
X