[kepler-dev] question about kepler
berkley at nceas.ucsb.edu
Wed Aug 20 10:12:08 PDT 2008
See my responses below.
> I have questions about actor's repository in kepler - it supports
> public/private access levels to simplify the process of uploading actors.
> So is it hard coded in kepler? Or maybe it is configured somewhere? So I
> understand PUBLIC/PRIVATE that are roles? Can I extend somehow the
> available roles?
The access is controlled by the metacat server on which the repository
runs. The Kepler client does not yet have the needed UI to allow users
to set the access control so it's currently hard coded to default to
> Metacat supports fine grained, role-based access control of the objects
> it stores - so is it possible to extend roles supported in kepler as a
> client to the metacat?
This is possible and will be implemented whenever we begin work on the
repository again. It's been stalled for a while while we work on other
parts of the project. I imagine with the new Kepler-CORE project, the
repository will once again be worked on.
> You wrote that Metacat was one of candidates as the repository - could
> you mention here others which did you take into consideration and why
> Metacat was used actually?
Metacat was used because it is also one of the projects that we have
been working on and it integrates nicely with our other metadata based
projects. I don't remember off hand the other candidates.
> Could you explain also what exactly is stored in the repository? The
> whole KAR archive ? So I understand I can put into repository some
> completely new actor (with all classes and jars etc).
> And if I have some standard kepler installed somewhere I can connect to
> the repository and use this new actor - it is imported to the local
> directory with actors with all classes and libs?
The KAR file and a modified metadata description of the actor are stored
in the repository. Unfortunately, we have not yet implemented storing
class/jar files in the KAR file so right now, the only actors that
really work with the repository are the ones strictly defined in MoML
(i.e. Sinewave) or actors where all of the classes are in the base
installation of Kepler. We know this is a major limitation and it's on
our list of things to fix as soon as we start working on the repository
Hope this helps clear some stuff up.
> Matthew Jones wrote:
>> The actor repository allows you to upload an actor along with its MoML
>> document and documentation. The actor is stored in a Metacat server
>> (http://knb.ecoinformatics.org/software/metacat) and the documentation
>> is indexed to enable searching the repository through a web-based
>> interface. The repository can also be searched from within the Kepler
>> application to locate remote actors of interest. Metacat uses LDAP as
>> its directory server to authenticate users. Metacat supports fine
>> grained, role-based access control of the objects it stores, but we
>> currently are only supporting public/private access levels to simplify
>> the process of uploading actors. This could be reconsidered if there
>> is a use case for more access levels.
>> Kepler communicates with Metacat using the EarthGrid web services
>> interface. Any server that supports the appropriate web services
>> interface could technically be used as an actor repository within
>> Kepler. Metacat is one such server, and there may be others that would
>> be candidates.
>> You can indeed deploy a version of metacat at your institution and use
>> it for your actor repository by configuring the Kepler client to point
>> at the new repository.
>> Kepler automatically prompts a person to login when they attempt to
>> perform an operation requiring authentication, such as uploading an
>> actor to the repository. There is also a Login menu that allows
>> someone to login at any time.
>> In terms of web-based UIs, there are several efforts. Hydrant is
>> indeed an excellent example, but others are also developing systems.
>> The GEON project has been running Kepler in the GEON portal
>> successfully for several years, and Paul Allen at the Cornell
>> Laboratory of Ornithology is developing an interface for biodiversity
>> research. The interest in this topic is significant, and so we will
>> probably be forming a working group to improve Kepler's ability to be
>> run in a portal environment.
>> P.S. Please do not cross-post to kepler-dev and kepler-users -- pick
>> the appropriate list for your question -- most developers are on both
>> dejw wrote:
>>> Hi Jianwu again,
>>> I want to ask more about this below:
>>>>> 3. Actor repository - I understand that it is possible to have one
>>>>> common actor repository for some organization? Kepler uses LDAP for
>>>>> it? Are there some access rights for actors or something like this?
>>>>> Is it possible to grant some roles to users when LDAP
>>>>> authentication is used? Is it possible to require login while
>>>>> starting Kepler?
>>>> You can find the current actor repository at
>>>> http://library.kepler-project.org/kepler/. Yet it is not widely used
>>>> currently. We are trying implement more comprehensive actor
>>>> repository mechanism.
>>> 1. So you use LDAP server to store actors? or something else?
>>> 2. How about access rights and user roles as regard access to actors
>>> in such repository?
>>> 3. I understand I can deploy such repository inside some organization
>>> and configure kepler to use it?
>>> 4. Can I set kepler to require login before start editor? to
>>> recognize user somehow?
>>> Kepler-users mailing list
>>> Kepler-users at ecoinformatics.org
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev