The f4cli is designed to assist a user in interacting with the fcrepo. This is both interactively, and as a way to quickly script interactions for batch applications development. In addition, the cli standardizes certain aspects of how the fedora repository is used. These include areas like access control and authentication.
Scenario templates
There are currently two proposed templates, the ldp and pcdm templates. The ldp framework is more simple; the pcdm follows the Portland common data model format. The different template affects how some tools work below.
In general, using a specific template adds additional type information to the system, and also checks for internal consistency within a system.
Application Features
Configuration
The order of the configuration of the command should be:
If there is a --config command-line use that file. Otherwise if there is a config file in the CWD then use that, otherwise if there is one on $HOME, use that. --config=*filename* You can specify an alternative config file on the command line if you use --config=, then no config file is included.
Then any command line parameters can override the configuration file.
Some commands may override the default parameters, for example you might update the prefixes for one command.
There should also be a nice way to update the configuration file from the cli if required. Maybe we have a config.save command?
# To see the current config
cli config.show # or cli config show?
# To update the config
cli --base=http://localhost:3000/app config save
# To save to a new location
cli --config=.clirc --base=http://localhost:3000 config.save
# To see what config file is being read
cli config config-file
Namespace Prefixes
I think it's useful for the tool, esp the interactive component to have a set of predefined prefixes that can be used. This is really helpful for small puts and patches. I understand that for some inputs however, you don't want to include prefixes. I think by default, we should include a list of namespaces, but the user can remove this list with --no-ns. For any command the, the command-line variable --ns=foo:http://foo.com should allow a new namespace to be defined.
If we actually end up parsing turtle, then we can be a bit more clever in this regard, only adding prefixes to ones that aren't included. This would eliminate most confusion with this. However, don't necessarily need to parse the turtle for this to be useful.
To see the defined namepaces we should be able to
cli config.ns
# TO add a new ns
cli --ns=foo:http://foo.com config.save
# To delete a NS
cli --ns=foo: config.save
Some commands should allow override of these (this is mostly for the interactive?)
cli PUT --no-ns <<< '@prefix foo <http://foo.com>. <> a foo:bar'
Access Control
While the cli tool will not impose any specific ACL setup on the framework, it will have methods specifically designed for the default ACL that the libraries LDP setup includes.
The system standard <info:fedora/etc/acl>
The system maintains one system Acl. This is located under the
/etc/acl directory structure. Generally, authorizations are directly under that container, with descriptive names for the authorizations. Only system administrators should have any write access to this ACL. All system files are defined with this ACL.
Those wishing to use this ACL, use the following parameter in their container.
<> acl:accessControl <info:fedora/etc/acl>
Agent ACL <info:fedora/etc/agent/$agent/acl>
When any other agent is given write access to a container, they have the ability to define their own Access control roles to that container. They are free to use any acl:Acl they have read access to, including those of other users. They are also free to create their own Acl sets. By default/ the
/etc/agent/quinn
In addition, the system, may assign writeable locations to particular groups
/etc/acl/group/eastman (writeable by group eastman)
Scenario 1
User wants to make a new container they only they are able to read and write to.
The user creates an authorization that
Parsing turtle files?
Commands
login
By default, the application should connect to the F4 instance without credentials. This is by default the EVERYONE user in the F4 parlance. Otherwise login to the system using either a local or CAS (for now) authentication. Maybe we could use emails as a method to decide which by default.
I guess by default, CAS should be in a manner similar to Google tools where an existing browser is used to carry out the login request. This makes it more difficult to maintain login when tokens expire, but seems to be the most consistent method. For expired tokens, we should probably just act as if the user was no longer logged in?
The only way that an admin user should identified to F4 is via the admin parameter in the JWT token. Users must also explicitly request this admin token. The token server has a list of what users have administrative authorization.
In addition, administrators have the ability to assign themselves any principal role to the system. This allows for easier testing.
Any login command should return the JWT token. If that is just part of the fully returned Header/Body information from the server as defined by the --print parameter, that's perfectly fine.
# Login to the CAS system
cli> login --cas quinn
# Login Locally
cli> login --local --password=${SECRET} qjhart
# Login as an administrator
cli> login --admin --cas quinn
# As an administrator login as another principal
cli> login --principal=jrmerz --cas quinn
cli> login --principal=dams-bot --admin --cas quinn
In addition, the configuration file should maintain. I don't know if a .netrc file format could make this sticky accross multiple accesses (like httpie), or if that's something we'd even want.
# Login and save to you're config
cli login --cas --admin quinn config.save
cli -d acl GET # This works!
Removing Data (rm)
We would like to be able to delete resources, quickly and perhaps recursively. However, recursiveness might depend on the template in place.
By default the fcr:tombstone should stay, but we can remove it with a flag.
# Delete a record
cli rm foo
# Delete a record and it's tombstone
cli rm -f foo ; cli rm --force bar; cli rm --tombstone baz
# recursively delete a conrtainer
cli rm -rf foo;
I don't think we should include wildcards. It would be interesting to see about adding SPARQL queries as a possibility though.
Adding data
We should be cognizant of the fact that F4 is not a filesystem, and maybe be a little concerned about how we add *nix style command to this
mkdir
Adding data touch
Adding data (put)
cli -d acl put <<< '<> a webac:acl'
cli put
## Templates
## Identifiers
## Output
### Colors
## Raw HTTP requests
GET PUT OPTIONS PATCH
Scenarios
The f4cli is designed to assist a user in interacting with the fcrepo. This is both interactively, and as a way to quickly script interactions for batch applications development. In addition, the cli standardizes certain aspects of how the fedora repository is used. These include areas like access control and authentication.
Scenario templates
There are currently two proposed templates, the ldp and pcdm templates. The ldp framework is more simple; the pcdm follows the Portland common data model format. The different template affects how some tools work below.
In general, using a specific template adds additional type information to the system, and also checks for internal consistency within a system.
Application Features
Configuration
The order of the configuration of the command should be:
--configcommand-line use that file. Otherwise if there is a config file in the CWD then use that, otherwise if there is one on $HOME, use that.--config=*filename*You can specify an alternative config file on the command line if you use--config=, then no config file is included.There should also be a nice way to update the configuration file from the
cliif required. Maybe we have aconfig.savecommand?Namespace Prefixes
I think it's useful for the tool, esp the interactive component to have a set of predefined prefixes that can be used. This is really helpful for small puts and patches. I understand that for some inputs however, you don't want to include prefixes. I think by default, we should include a list of namespaces, but the user can remove this list with
--no-ns. For any command the, the command-line variable--ns=foo:http://foo.comshould allow a new namespace to be defined.If we actually end up parsing turtle, then we can be a bit more clever in this regard, only adding prefixes to ones that aren't included. This would eliminate most confusion with this. However, don't necessarily need to parse the turtle for this to be useful.
To see the defined namepaces we should be able to
Some commands should allow override of these (this is mostly for the interactive?)
Access Control
While the cli tool will not impose any specific ACL setup on the framework, it will have methods specifically designed for the default ACL that the libraries LDP setup includes.
The system standard
<info:fedora/etc/acl>The system maintains one system Acl. This is located under the /etc/acl directory structure. Generally, authorizations are directly under that container, with descriptive names for the authorizations. Only system administrators should have any write access to this ACL. All system files are defined with this ACL.
Those wishing to use this ACL, use the following parameter in their container.
Agent ACL
<info:fedora/etc/agent/$agent/acl>When any other agent is given write access to a container, they have the ability to define their own Access control roles to that container. They are free to use any acl:Acl they have read access to, including those of other users. They are also free to create their own Acl sets. By default/ the
In addition, the system, may assign writeable locations to particular groups
Scenario 1
User wants to make a new container they only they are able to read and write to.
Parsing turtle files?
Commands
login
By default, the application should connect to the F4 instance without credentials. This is by default the EVERYONE user in the F4 parlance. Otherwise login to the system using either a local or CAS (for now) authentication. Maybe we could use emails as a method to decide which by default.
I guess by default, CAS should be in a manner similar to Google tools where an existing browser is used to carry out the login request. This makes it more difficult to maintain login when tokens expire, but seems to be the most consistent method. For expired tokens, we should probably just act as if the user was no longer logged in?
The only way that an admin user should identified to F4 is via the admin parameter in the JWT token. Users must also explicitly request this admin token. The token server has a list of what users have administrative authorization.
In addition, administrators have the ability to assign themselves any principal role to the system. This allows for easier testing.
Any login command should return the JWT token. If that is just part of the fully returned Header/Body information from the server as defined by the
--printparameter, that's perfectly fine.In addition, the configuration file should maintain. I don't know if a .netrc file format could make this sticky accross multiple accesses (like httpie), or if that's something we'd even want.
Removing Data (rm)
We would like to be able to delete resources, quickly and perhaps recursively. However, recursiveness might depend on the template in place.
By default the fcr:tombstone should stay, but we can remove it with a flag.
I don't think we should include wildcards. It would be interesting to see about adding SPARQL queries as a possibility though.
Adding data
We should be cognizant of the fact that F4 is not a filesystem, and maybe be a little concerned about how we add *nix style command to this
mkdir
Adding data touch
Adding data (put)