This page is old; please merge its content into the Wiki and delete it!

ARC1 libraries feedback

  • Everytime aaction requiring authenticated access to ARC services, an instance of Credential is created. The init process of Credential implies a verification step that checks the proxy and the local credential. This step is repeated every time (for every job) and it make our effort in caching Grid Auth module in GC3Pie useless

  • Quite a lot of libraries modules are loaded; this is iterated several time regardless on whether the library has been already loaded (at least this is what ARC logger reports)

Our requirements for ARC1 client library

  • "long-running" use case

    Need to manipulate objects without having to rebuild them (especially if we need to rebuild a whole chain of objects just to change one parameter).

    Example: the UserConfig instance must be re-created if we need to modify job status filters.

  • control over network/LDAP searches: explicitly cache results

    Known which methods can trigger WS/LDAP searches and have a way not to call them.

    Have a way to store and re-use the results of network accesses/searches.

  • make credential management optional

    Everytime an action requiring authenticated access to ARC services, an instance of Credential is created. The init process of Credential implies a verification step that checks the proxy and the local credential. This step is repeated every time (for every job!) and it make our effort in caching Grid Auth module in GC3Pie useless.

  • Data managing It would be nice to have a buffered data transfer (like in the FTPController). It is necessary, sometimes, to transfer only portion of the remote file (like for the log) It is imperative to have remote file size information what is the purpose of FileCache ?

Interface design complaints

  • unclear separation of concerns in the ARClib interface objects

    Example 1: Jobs are added to a jobStore via JobSupervisor.addJob, but removed via JobController.cancelJob.

    Example 2: Jobs are submitted through ExecutionTarget.submit, and then one needs to update the jobStore manually via JobSupervisor.addJob.

  • mix of functional and object-oriented programming styles

    Most methods require "state" objects to be passed as a parameter. Example: UserConfig or a jobStore.

    In a OO setting, these should rather be object attributes (since it's object state).

    In a functional setting, all state will be kept in structures and passed as argument to functions.

    Pick the style better suited to the ARC model and the stick with it!

Misc. bugs

  • BUG: automated module loading loads everything for every action.

    Quite a lot of libraries modules are loaded; this is iterated several time regardless on whether the library has been already loaded (at least this is what ARC logger reports).

    This makes the module system almost completely useless -- it's exactly as if anything had been compiled in.

top