[kepler-dev] breaking off a kepler-docs repository
Dan Higgins
higgins at nceas.ucsb.edu
Fri Aug 5 11:13:26 PDT 2005
Let me throw in some related comments (not on the KSW system, but on
different project groups).
I recently went through the entire current actor tree and built a
simple text file showing ALL the actors currently in the tree. (see
kepler/docs/dev/actorLibraryDesign/ActorTree.txt; also see
kepler/docs/dev/actorLibraryDesign/actorOntology.gif). There are now
approximately 340 actors! Unfortunately, I am not sure anyone
understands just what all these actor do (especially ones from different
groups). As an example, I noticed that we have 4 'Constant' actors
that all do almost the same thing (see attachment) and I think we really
need to consider whether we need all the actors that are currently in
the actor tree. (Also, many seem to be in the wrong place in the
ontology; e.g. 'Interpolator', 'Quantizer', and 'Interpolate' are the
only actors under "Statistics' and none of them should be (in my
opinion)). At some point, I think we need to review all the efforts and
determine just what actors are really of universal use and make that the
Kepler 'base-set'. Showing all the project specific actors is getting
too confusing as the numbers continue to increase.
Dan
----
Chad Berkley wrote:
>I don't think the KSW/ObjectManager system will really have an impact on
>custom builds, unless you're talking about custom releases (which I
>think are different). The objman should allow you to create your own
>ontology for the system and just load the actors (from KSW files) that
>are specific to that ontology. So you could have a GEON ontology and
>just have a GEON specific release with relevant components. As far as
>building and daily development goes, I don't see the objman affecting it
>very much.
>
>chad
>
>Bertram Ludaescher wrote:
>
>
>>Indeed, the project-oriented splitting had been discussed before (and
>>project boundaries are not always clear, e.g., if someone from SEEK
>>helps someone from SPA (or Geostreams ;-) to jointly write an
>>actor. Where does it go??
>>
>>Chad, could you briefly summarize (or point us to the respective docu)
>>how the new KSW (KAR ;-) and/or object manager approach might help the
>>problem of project-specific/custom builds? It seems that under the new
>>approach, one could just have a "minimal" Kepler build and then
>>dynamically discover components (actors, workflows, datasets)..
>>
>>Bertram
>>
>>Chad Berkley writes: > Hi Carlos,
>> >
>> > The problem I see with this is that it divides kepler into project
>> > specific lines where what we're trying to do is create a cross project
>> > modeling platform. Our src directly was already divided similarly to
>> > this and it caused numerous problems with organization so we've been
>> > trying to move stuff to the org.kepler tree. Also, reorganizing stuff
>> > on that level at this point would be a nightmare.
>> >
>> > chad
>> >
>> > Carlos A. Rueda wrote:
>> > > Dear kepler-ers,
>> > > I think having the two modules kepler/pubs and kepler/dev is a very
>> > > good idea. In fact (knowing that the current KSW efforts might
>> > > supersede the following suggestion somehow), I would suggest even go
>> > > further and split up the /dev module into submodules corresponding to
>> > > projects, something like:
>> > > kepler/dev/core
>> > > kepler/dev/projA
>> > > kepler/dev/projB
>> > > ...
>> > >
>> > > with each component (submodule) coming with its own build files
>> > > (build.xml, properties, etc.) and dependencies only on those other
>> > > required modules.
>> > >
>> > > Developer-users would be able to check out only the desired
>> > > components. This way one can avoid dealing always with the "heavy"
>> > > kepler and instead work with the minimum set of components required to
>> > > try and test new developments.
>> > >
>> > > carlos
>> > >
>> > > Bertram Ludaescher wrote:
>> > >
>> > >>Chad Berkley writes:
>> > >>...
>> > >>
>> > >> > a slightly different way. Say kepler/dev and kepler/pubs. That way if
>> > >> > you only want the code part you could do 'cvs co kepler/dev' If you
>> > >> > want it all, you would do 'cvs co kepler'. Just a thought.
>> > >>
>> > >>Looks like that easiest fix to me. Any objections to this suggestion?
>> > >>(Would take care of both Chad's problem and the concern that Laura raised)
>> > >>
>> > >>BTW, I also think that a document management might be too much effort
>> > >>right now. An interesting project though for someone who is interested
>> > >>in that topic ..
>> > >>
>> > >>Bertram
>> > >>
>> > >> >
>> > >> > chad
>> > >> >
>> > >> > Laura L. Downey wrote:
>> > >> > > I thought the point was having everything in one place -- which is important
>> > >> > > with a distributed project. At least that is the impression I've gotten
>> > >> > > from Matt.
>> > >> > >
>> > >> > > It would seem that people are "checking out" instead of "updating" with CVS
>> > >> > > because update is much quicker. But I think I remember Dan telling me the
>> > >> > > other day that it is "safer" to check out than to update.
>> > >> > >
>> > >> > > I'm fine with whatever is decided, keeping things together or splitting them
>> > >> > > apart. My only comment is that the more repositories we have and the more
>> > >> > > places we have to go to get and put data (docs, code etc), the more upkeep
>> > >> > > that is for everyone.
>> > >> > >
>> > >> > > Laura L. Downey
>> > >> > > Senior Usability Engineer
>> > >> > > LTER Network Office
>> > >> > > Department of Biology, MSC03 2020
>> > >> > > 1 University of New Mexico
>> > >> > > Albuquerque, NM 87131-0001
>> > >> > > 505.277.3157 phone
>> > >> > > 505.277-2541 fax
>> > >> > > ldowney at lternet.edu
>> > >> > >
>> > >> > >
>> > >> > > -----Original Message-----
>> > >> > > From: kepler-dev-bounces at ecoinformatics.org
>> > >> > > [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
>> > >> > > Sent: Thursday, August 04, 2005 12:02 PM
>> > >> > > To: Chad Berkley
>> > >> > > Cc: Kepler-Dev
>> > >> > > Subject: Re: [kepler-dev] breaking off a kepler-docs repository
>> > >> > >
>> > >> > >
>> > >> > > I think it is a good idea to *not* include the various publications and
>> > >> > > presentations concerning Kepler in the code repository (cvs).
>> > >> > >
>> > >> > > I wonder, however, if having a separate cvs for documents is the way to
>> > >> > > go. Instead, maybe we should consider using a more traditional approach
>> > >> > > like a document management system? I'm sure there are a number of
>> > >> > > open-source/free ones out there (e.g., zope and plone are popular ones,
>> > >> > > the stanford publication server is an older one). Perhaps there are
>> > >> > > also extensions of the wiki for this?
>> > >> > >
>> > >> > >
>> > >> > > -shawn
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > Chad Berkley wrote:
>> > >> > >
>> > >> > >>Hi all,
>> > >> > >>
>> > >> > >>As I sit here checking out kepler (again), waiting forever for the docs
>> > >> > >>directory to finish, it occured to me that it might be ok to have a
>> > >> > >>different cvs repository for kepler docs. there's no reason why a
>> > >> > >>developer should have to checkout out a myriad of .doc and .ppt files
>> > >> > >>everytime you need a new version of kepler. It seems to me that docs
>> > >> > >>that actually go with the kepler software should stay in the kepler
>> > >> > >>repository, but publications, reports and the like could be stashed
>> > >> > >>somewhere else. Anyone have any reasons why this would be a bad idea?
>> > >> > >>
>> > >> > >>thanks,
>> > >> > >>chad
>> > >> > >>_______________________________________________
>> > >> > >>Kepler-dev mailing list
>> > >> > >>Kepler-dev at ecoinformatics.org
>> > >> > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > >> > >
>> > >> > >
>> > >> > > _______________________________________________
>> > >> > > Kepler-dev mailing list
>> > >> > > Kepler-dev at ecoinformatics.org
>> > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > >> > >
>> > >> > > _______________________________________________
>> > >> > > Kepler-dev mailing list
>> > >> > > Kepler-dev at ecoinformatics.org
>> > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > >> > _______________________________________________
>> > >> > Kepler-dev mailing list
>> > >> > Kepler-dev at ecoinformatics.org
>> > >> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > >>
>> > >>_______________________________________________
>> > >>Kepler-dev mailing list
>> > >>Kepler-dev at ecoinformatics.org
>> > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > >>
>> > >
>> > > _______________________________________________
>> > > Kepler-dev mailing list
>> > > Kepler-dev at ecoinformatics.org
>> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> > _______________________________________________
>> > Kepler-dev mailing list
>> > Kepler-dev at ecoinformatics.org
>> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>
>>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
--
*******************************************************************
Dan Higgins higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS)
Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TooManyActors.txt
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20050805/ef9b6526/attachment.txt>
More information about the Kepler-dev
mailing list