Personal tools
You are here: Home
Log in


Forgot your password?
New user?
 

Modified items

All recently modified items, latest first.
Architecture teminology by Timothy McPhillips, last updated: Oct 28, 2008 12:55 PM
New Documents in Architecture Team Area by Kirsten Menger-Anderson, last updated: Oct 28, 2008 12:54 PM
Architecture Team charter by Development Account, last updated: Oct 28, 2008 12:53 PM
Re: Framework Team charter by Matthew Jones, last updated: Oct 28, 2008 12:53 PM
We've made changes to the charter, renaming this group the Architecture Team.  This complements other naming changes that have transpired while writing the Management Charter.
Architecture Team by Development Account, last updated: Oct 28, 2008 12:50 PM
A discussion forum for the architecture team.
Re: Collaboration tools by Matthew Jones, last updated: Oct 28, 2008 12:48 PM
Shaun -- Christopher has pointed out that individual forum threads do not have the RSS links for that forum -- could those be added to the plone UI?
Re: Build System Requirements by Christopher Brooks, last updated: Oct 28, 2008 10:11 AM
Ok, sorry for the late arrival.  I read Chad's proposal which seemed quite good.  Like David, I pretty much agree with everything Chad says, which is good.   The one item which might be an issue concerns having every actor be a module.  I think this might be too fine grained.  I do see that Chad is saying a module _may_ consist of just one actor, but a module may consist of multiple actors.   In thinking about module granularity, it seems like authors want their work to be in very fine grained modules and users want large, fairly monolithic modules.  I see this when people one Ptolemy as one module, but I say, "But ptolemy consists of several products: gui, headless, plotter, hyvisual, ptiny, visualsense, viptos".  There is this inherent tension about module size.  I think Aaron or someone suggested that modules should be large and modules should only be split up to create deliverables.  I like this notion.   One pattern I'm looking at is having a few smaller, fine grained modules at the base of ptolemy and then some fairly large modules to support actor semantics and common groups of actors and then fine grained modules to support special actors that use third party features.   About Bertram's discussion about actors and configurations, we did quite a bit of work with Actor Oriented Classes, where Edward basically applied object oriented inheritance to actors.  See http://chess.eecs.berkeley.edu/pubs/314.html. This work covers some of the issues of how composite actors get instantiated and subclassed over time.  It might be useful to look at composite actors to get some understanding of how atomic actors need to behave. The Ptolemy documentation system also has this element of actors getting annotated with comments that is interesting where instances have comments attached to them. One issue is that most people quickly get flustered with a complex versioning system.  There are just too many choices and possibilities.  I'm not sure how to avoid these issues.   _Christopher
Re: Collaboration tools by Christopher Brooks, last updated: Oct 28, 2008 09:42 AM
  Ok, I can subscribe to https://dev.kepler-project.org/recent-changes/RSS - The title should probably be changed from "<title>Recent Changes</title>" to "<title>dev.kepler-project.org Recent Changes</title>" or something similar.  When I add the feed to Thunderbird, it just says "Recent Changes", which is not that helpful.  I was able to change the title in Thunderbird, but everyone who subscribes will need to change the title.  However, changing the title _could_ cause problems with current subscribers. - It would be nice if https://dev.kepler-project.org/developers has RSS icons on the right hand side in the recent changes column.  To find out about the RSS feed, I had to search the website for RSS.  I looked in my own user settings for ways to subscribe to changes, but did not see anything there. - I find the recent changes feed interesting, but confusing. The feed brings up web pages that have changed, I have no idea what's changed though. - Would it be possible to get a feed for recent messages?  Ideally, the feed would be just textual, without the surrounding web page.  The feed should be titled something like "dev.kepler recent messages". BTW - an RSS feed mostly meets my needs, but an email interface for recent message that would allow me to read recent messages and post responses would be ideal.  I know that posting responses is a lot to ask.  I'll settle for the RSS feed in the near term.
Re: Build System Requirements by Bertram Ludaescher, last updated: Oct 27, 2008 07:11 PM
All,  I'd like to also suggest to revisit the conceptual model of actors, actor configurations etc. and clarify some of the notions. A little bit terminology might go a long way. For example, it seems that we have quite a few actors who can be *configured* in various ways (to have or not have certain ports, to have certain default parameter values or not etc.) and they can be *annotated*. Many actors have a "Java core", but then some don't. It seems we're having a bit of an "actor identity crisis" here... ;-) Let's focus for the moment only on Java actors. Say you have an actor X.java. So this code is the "heart" of actor X. Now various people start using this actor, creating different (semantic) annotations, different default parameter values etc. Let's call these different configurations of the actor X.c1, X.c2, X.c3. Now a user starts to employ X.c2 but then decides she wants to change part of the configuration c2. So we have X.c2'. So far so good. So let's dump all these new "actors" (or shall we say, "configured actors"!?) into a repository -- here we go: repository = { ..., X, X.c1, X.c2, X.c2', X.c3 ... } So far so good. Now the author of X sees that a bug needs to be fixed in X, creating X' from X. What happens now to X.c1, X.c2 etc? My suggestion would be to keep the existing configuration as they are, referring back to the old (possibly buggy or more limited) version X. But it would be wonderful if the owners of X.c1, X.c2 etc would learn of the *possibility* to upgrade their internal "X core" from X to X'. In summary, it seems, at least for Java actors, a distinction between the actor *code* and actor *configurations* could be helpful. A versioning system should be able to "do the right thing" and allow evolution of the code base and of configurations largely separately, while keep track of dependencies and version histories. Does that make sense? I have an MS student (Erick) who is beginning to look into these matters... Your comments would be much welcome.. cheers Bertram
Requirements by Aaron Schultz, last updated: Oct 27, 2008 06:06 PM
Architecture Team Requirement Documents
Design Docs by Aaron Schultz, last updated: Oct 27, 2008 06:06 PM
Design documents produced by Architecture Team participants
Road Map by Aaron Schultz, last updated: Oct 27, 2008 06:05 PM
Architecture Team planned and proposed milestones and activities.
Architecture Team Charter by Matthew Jones, last updated: Oct 27, 2008 06:04 PM
Development Teams by Development Account, last updated: Oct 27, 2008 03:39 PM
Kepler development teams design, develop, test and deploy the software and infrastructure necessary for a functional extension, domain-specific extension, actor package, or other related product. Each development team operates under a charter (identifying the team's leader, mission, and scope) and maintains a road map that describes the current work plan and planned products. To create a new development team, a new team leader must submit a group charter, road map, and initial participant list to the Kepler Leadership Team, which reviews, edits, and approves the team. These materials can be developed in the Incubation area of the web site.
Infrastructure Teams by Development Account, last updated: Oct 27, 2008 03:39 PM
Kepler infrastructure teams focus on critical aspects of the Kepler framework and development infrastructure. Each team has a designated leader and operates under a charter that clearly states its mission and scope. The broad Kepler community is invited to participate in Kepler's infrastructure teams. Please see the individual team areas for more information about each.
Re: Build System Requirements by Timothy McPhillips, last updated: Oct 24, 2008 04:57 PM
Dan, this sounds extremely useful to me.  I'd like to be able to use this tool now, as well as possibly see it incorporated into the build system as you suggest.  Very cool!
Re: Build System Requirements by Daniel Crawl, last updated: Oct 23, 2008 02:09 PM
Hi Chad and Tim, I've written a tool to help automate the creation of KAR momls and manifests. It uses the existing code that gets executed when one manually exports an actor on the canvas, except it runs from the command-line, can do more than one actor at a time, and includes the documentation. Perhaps this could be used in the new build system to reduce the amount of metadata stored in the repository for each actor. We would still need a mechanism to provide the LSIDs and semantic annotations, but everything else in the KAR could be automatically generated. (Of course XML actors, and actors with additional ports, special default values, customized documentation, etc., would still need to be done by hand). If you think it'd be useful, I can work on cleaning up the code and adding to svn.   --dan
Re: Build System Requirements by Chad Berkley, last updated: Oct 22, 2008 10:33 AM
Ahh, I see what you're getting at I think.  I actually wasn't talking about putting kar files themselves into SVN at all.  Just the source that makes up the distributed versions of the kar.  The kar files are currently generated on-the-fly and are not in the repository.  If a user makes a change to an actor, they can create a new kar file and upload that to the actor repository (or to their local disk), but not to SVN.   I think one thing you're missing is that you're still assuming that all actors have java source when this is not the case.  Some actors are just XML files.  Take a look at Sinewave for an example.  Your example of people changing the actors and getting a new version of the actor without checking it in anywhere makes me think more about the ID process though.  This has been a thorn in my side for some time.  How do you get a unique ID for these types of objects when you might not have an internet connection?  I guess we could do some sort of unique hash of the actor and use that.   As far as repository structure though, I don't think the runtime actor creation/ID problem really plays into how we structure the repository to accommodate actor authoring.  I think there still needs to be a place in the repository where actors live, especially those that are in our core release(s) of kepler.  I'm still of the opinion that actors should just be treated like other modules and have their own repository structure.  Whether there is one actor in the structure or 10, I think is debatable (and to tell you the truth, I don't think is *that* important), but I just want to get a general repository structure outlines so we can start moving stuff around and get the build system(s) working with the new structure. Here's a link to the documentation we had when we developed the kar file format:  http://www.kepler-project.org/Wiki.jsp?page=KSWEncapsulationSpecification  Note they used to be called "ksw" files.  This documentation could probably be flushed out a bit more, but I think that might be the role of the framework team when we start working on the core functionality.  
Re: Build System Requirements by Timothy McPhillips, last updated: Oct 21, 2008 02:06 PM
Good points, Chad.  What I'm questioning here is not the need for an actor metadata language, associating metadata with actors, or the approach that Kepler takes in loading and displaying actors based on this metadata.  What I'm confused about is the need for version-controlled source files for KAR files.  Is the author of an actor the authority of the semantic annotations that are assigned to it, what ports the actors can have, what parameter values are assigned to it?  I thought anyone could customize an actor and save an updated KAR file.  But then don't these variant KAR files lack corresponding source files in the repository?  It seems to me that we can't have version-controlled (via SVN, I mean) sources for every KAR file out there and that might be usefully shared.  Why then do we expect version controlled KAR sources in the first place?  Do you see why I'm confused?  Can't we bootstrap to the first, barebones KAR file for an actor directly, without using a version-controlled directory of source files?  If we could, then creating a new actor would require simply compiling a new Java source file for the actor. I agree the Java-package based organization should not be the one we provide to scientists.  When playing the role of a workflow engineer, though, I'd like to be able to find all actors that are loaded in the JVM, via the library pane and search dialog, without specifically creating metadata files for each actor.  From there I could easily further annotate the actors I've created so that they show up in a more meaningful place in the library.  It'd be totally cool if the package-based organization were hidden by default. All:  Has anyone spelled out the usage scenarios for the KAR system, the Library, and repository showing how sharing of actors and actor metadata is expected to work, end-to-end?  I.e., from actor creation, through customizing one's own library, and sharing customizations of actors with others via the repository?  And including situations such as the destruction of one's .kepler directory?
Re: Build System Requirements by Chad Berkley, last updated: Oct 21, 2008 01:12 PM
I have to disagree with you that most people will develop many actors.  From my experience, most people have developed 1-5 actors in small blocks of development.  I think developing 35 actors is the exception. That having been said, I fully agree with you that the current system is too hard to deal with.  I really don't want people hand editing text files.  I actually never said that we would *require* each actor to be in a separate module (though, I think it was implied that I did say that).  In fact, I see no reason why a group of related actors couldn't be in the same module.   The editing of the actor metadata files by hand is obviously not optimal.  I tried to address this above where I called for going through with the idea of an actor development kit that would create this environment and make it easy to bootstrap.  The issue here is that ptolemy has many different ideas of what an actor is.  It can be a java object.  It can be an XML object.  It can have ports/parameters declared in java.    It can have ports/parameters declared in the xml.  When Shawn and I designed the actor metadata language, we were trying to eliminate all of that ambiguity and get everything declared in one place, hence the actor metadata file.  If we want to change or eliminate that, it is going to take some major reworking of the way Kepler loads actors and displays them to users. The semantic annotations are stored with the actor because they describe the actor.  Storing them externally to the actor would create ambiguity.  Storing them in the repository assumes that whenever you use Kepler, you have an internet connection.  Many of our users do not have this luxury.  In the past, the organization of the actor repository was done in a separate file which quickly turned into a huge mess when all 215 actors or more were assigned there.  The file was static and required commit privileges to the kepler configs to change.  I think allowing actor authors to edit their own annotations with the actor is a much more concise, organized way to do it.  It separates the the content from the structure of the library, which I think is also a good thing. Organizing actors by their classname would be great for java programmers like ourselves.  Unfortunately, I don't think geologists and ecologists would think this is such a great organization technique.  This is why we designed the ontology system so that other domains could organize how they saw fit.  We've been actively trying to hide things like java classes from Kepler users as to not alienate our domain scientist user base.  Having a default sort order like this would turn off many ecologists.  I think this might be nice as an option, but we should be able to turn it off for releases to domain scientists.  The way I think of this, it's more like giving an actor developer their own little piece of space to develop in.  Everything is self-contained and it has a standard directory structure.  For the default set of actors, I could write a script to transfer them from their current directory structure to this new structure in about 10 minutes.  I think having the extra overhead and directory structure is worth it to keep the actors modularized and not create special cases to deal with later.
 
« Previous 20 items Next 20 items » 1 … 29 30 31 32 33 34 35 … 46