[saga-rg] Current issue list

Wed Jul 6 23:28:41 CDT 2005

During the phone call, we annotated part of the list with
TODOs and comments.  Here it is for archiving purposes, you
can also find it in CVS.

The call was joined by

  - Tom Goodale
  - Christopher Smith
  - Shantenu Jha
  - Thomasz Haupt
  - Andre Merzky

The next call will be in two weeks, Thursday July 21st, same
time.

Cheers, Andre.

Quoting [Tom Goodale] (Jul 07 2005):
> Date: Thu, 7 Jul 2005 10:22:35 -0500 (CDT)
> From: Tom Goodale <goodale at cct.lsu.edu>
> To: saga-rg at ggf.org
> Subject: [saga-rg] Current issue list
> 
> 
> Peter  Kunszt <Peter.Kunszt at cern.ch>
> Kalman Kovari <Kalman.Kovari at cern.ch>
> 
>   - The examples are sometimes more misleading than useful...
> 
>     -> why?
> 
> 
>   - The error handling and error semantics are not defined well
>     enough.  This is essential in order to assure proper
>     interoperability.
> 
>     -> compile list of error codes, check for consistency
> 
> 
>   - There is a lack of structure in terms of interface layering.  High
>     level interfaces (like JobManagement) and low level interfaces
>     (like Stream) are not distinguished, motivated, or put into
>     context.  E.g. why is there a need of a networkstream-level
>     interface for a grid application?
> 
>     -> intentional, see use cases!
> 
> 
>   - Example (P18): OO structured, not like the iface.
>     (eg. i = dir.getNumEntries() instead of dir.getNumEntries(a) ? )
> 
>     -> ?
> 
> 
>   - Example (P29): an exact copy of Ex. 1.
> 
>     -> check
> 
> 
>   - Description - Streams (P62): close or destroyStream? maybe close,
>     but not consistent.
> 
>     -> see Notes in Streams
> 
> 
>   - General: sometimes bitwise OR-s are used for multiple options
>     (Stream/ActivityType, P59), sometimes arrays of values
>     (NameSpace/CopyFlags, P9). Why no convention?
> 
>     -> I agree, bitwise OR is simplier
> 
> 
>   - Interface NSDir: what are the semantics of the copy method? of
>     getName and getURL?
> 
>     -> ?
> 
> 
> Thorsten Sch"utt:
> 
>   - isFile -> isEntry?
> 
>     -> should we revive NSEntry (more reasons?)?
> 
> 
>   - SIDL docs on wiki!
> 
>     -> TODO
> 
> 
>   - fix all examples in respect to session and context
> 
>     -> TODO
> 
> 
>   - flags
> 
>     -> see above
> 
> 
>   - Attribute -> AttributeSet
> 
>     -> leave naming, but better describe idea
> 
> 
> Steven Newhouse:
> 
>   - Inconsistent use of security!  Its only in the stream section,
>     nowhere else. "Not specifying a security system makes sense, but I
>     think all of thes emethods should have a security token being
>     passed into them or it should be an argument in the relevant
>     object constructor."
> 
>     -> should be fixed by session and context
> 
> 
>   - I assume the URL can support a number of protocols -
>     http/https/file/gridftp. I see no way to register plugins in the
>     interface (may be this is an 'internal' interface as opposed to a
>     user funtion. Maybe there needs to be aet of interfaces to help
>     the developers, e.g. register protocol plugins.
> 
>     -> plugin: implementation level
>     -> url support: util class?  any://?
> 
>   - State example language each time!  Do examples in multiple
>     languages!
> 
>     -> TODO
> 
> 
>   - How are you going to handle partial functionality implementations?
>     Should _all_ operations support a NotImplementedException ? Should
>     there be a standard static method in each section to discover what
>     is implemented? e.g. supported protocols & supported methods.
> 
>     -> methods need ALL to be implemented.
>     -> protocols etc: hmmm...
> 
> 
>   - You have an 'LSF' schema for >>, >, < & <<. But in the
>     file/directory area you use a series of attribute flags. I think
>     you should carry these attribute flags forward into the job
>     definition area - either way I think you should have one model not
>     two!
> 
>     -> Chris, Andre: resolve!
> 
> 
>   - I.   General Model.
>          Language mapping.
>          Standard attribute model.
>          Security.
>          Tasks
>     II.  Tier 1 Interfaces.
>     III. Tier 2 and above Interfaces.
> 
>     -> II and III on same level!
> 
> 
>   - What is to come in version 2?
> 
>     -> - steering and monitoring
>        - possibly combining logical/physical files (read on
>          logical files)
>        - advert service
>        - GridRPC
>        - GridCPR
>        - Task dependencies (simple work flows and batches)
>        - extensions to existing classes
>        - we have no explicit roadmap!!
> 
> Others:
> 
>   - 'The URL Problem'
> 
>     -> should we approach it?
> 
> 
>   - advert service
> 
>     -> easy: NS + Attribute + find on attribute!
>        why not do it?
> 
> 
>   - find in name spaces?
> 
>     -> why not, at least for names!?
>        But over attributes?  What about query language then?
> 
> Andre:
>   - list only on dir - why not on file?
> 
>   - go from getSize to real stat
> 
>   - namespace ops on files - why not on wildcards?
> 
>   - should callbacks be introduced for some things?  Best on tasks,
>     but also for streams (is factory!)  Necessary for
>     monitoring/streaming, so best introduce in general...
> 
>   - integrate GridRPC / GridCPR / JSDL?  What else?
> 
>   - check if bulk operations can be done with task containers
>     (explicit support needef for argument list generations?)
> 
>   - ACLs
> 
>   - Authorization (call outs?)
> 
>   - task = ftf.read (1, buffer, &n);
>     task.run ();
> 
>     When are 'n' and 'buffer' available?  I would say after wait.
> 
> 
> 
> 
> GGF14:
>   - who sends UC doc to editors?
> 
> +-------------------------------------------------------------+

-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+
-------------- next part --------------

---------------------------------------------------------------------

Peter  Kunszt <Peter.Kunszt at cern.ch>
Kalman Kovari <Kalman.Kovari at cern.ch>

  - The examples are sometimes more misleading than useful...

    -> why?
    -> TODO ANDRE: clearify, discuss on list

  - The error handling and error semantics are not defined well
    enough.  This is essential in order to assure proper
    interoperability.

    -> compile list of error codes, check for consistency
    -> TODO TOM: create proposal for procedural and OO

  - There is a lack of structure in terms of interface layering.  High
    level interfaces (like JobManagement) and low level interfaces
    (like Stream) are not distinguished, motivated, or put into
    context.  E.g. why is there a need of a networkstream-level
    interface for a grid application?

    -> intentional, see use cases!  
    -> TODO ANDRE: CLEARIFY in intro

  - Example (P18): OO structured, not like the iface. 
    (eg. i = dir.getNumEntries() instead of dir.getNumEntries(a) ? )

    -> TODO ANDRE: cleanup, also session handle etc.

  - Example (P29): an exact copy of Ex. 1.

    -> check

  - Description - Streams (P62): close or destroyStream? maybe close,
    but not consistent.

    -> see Notes in Streams
    -> TODO ANDRE: use <constructor> or so. - check SIDL

  - General: sometimes bitwise OR-s are used for multiple options
    (Stream/ActivityType, P59), sometimes arrays of values
    (NameSpace/CopyFlags, P9). Why no convention? 

    -> I agree, bitwise OR is simplier
    -> TODO ANDRE: check for languages, fix

  - Interface NSDir: what are the semantics of the copy method? of
    getName and getURL?

    -> ?
    -> TODO ANDRE: ask for clearification, sync with GFS

Thorsten Sch"utt:

  - isFile -> isEntry?

    -> should we revive NSEntry (more reasons?)?
    -> TODO ANDRE: ask mailing list

  - SIDL docs on wiki!

    -> TODO TOM/JOHN

  - fix all examples in respect to session and context

    -> TODO ANDRE.

  - flags 

    -> TODO ANDRE: see above

  - Attribute -> AttributeSet 

    -> TODO TOM: leave naming, but better describe idea

Steven Newhouse:
----------------

  - Inconsistent use of security!  Its only in the stream section,
    nowhere else. "Not specifying a security system makes sense, but I
    think all of thes emethods should have a security token being
    passed into them or it should be an argument in the relevant
    object constructor."

    -> should be fixed by session and context
    -> TODO ANDRE

  - I assume the URL can support a number of protocols -
    http/https/file/gridftp. I see no way to register plugins in the
    interface (may be this is an 'internal' interface as opposed to a
    user funtion. Maybe there needs to be aet of interfaces to help
    the developers, e.g. register protocol plugins.

    -> plugin: implementation level
    -> url support: util class?  any://? -> language specific
    -> need good error codes

  - State example language each time!  Do examples in multiple
    languages!

    -> TODO: 

  - How are you going to handle partial functionality implementations?
    Should _all_ operations support a NotImplementedException? Should
    there be a standard static method in each section to discover what
    is implemented? e.g. supported protocols & supported methods.

    -> methods need ALL to be implemented.  
    -> protocols etc: hmmm...
    -> discussed at GGF, DONE

  - You have an 'LSF' schema for >>, >, < & <<. But in the
    file/directory area you use a series of attribute flags. I think
    you should carry these attribute flags forward into the job
    definition area - either way I think you should have one model not
    two! 

    -> was discussed at GGF...
    -> there WILL be partial implementation, but they are not SAGA
       conform then.
    -> necessary  (session, context, ...) 
    -> sufficient (one other subsys)
    -> CAN implement subsystems -> complete subsystems (partial
       compliant)
    -> TODO ANDRE

---------------------------------------------------------------------

  - I.   General Model. 
         Language mapping. 
         Standard attribute model. 
         Security. 
         Tasks
    II.  Tier 1 Interfaces.
    III. Tier 2 and above Interfaces.

    -> II and III on same level!

  - What is to come in version 2?

    -> - steering and monitoring
       - possibly combining logical/physical files (read on
         logical files)
       - advert service
       - GridRPC
       - GridCPR
       - Task dependencies (simple work flows and batches)
       - extensions to existing classes
       - we have no explicit roadmap!!

Others:

  - 'The URL Problem' 

    -> should we approach it?

  - advert service

    -> easy: NS + Attribute + find on attribute!
       why not do it?

  - find in name spaces?

    -> why not, at least for names!?  
       But over attributes?  What about query language then?

Me:
  - list only on dir - why not on file?

  - go from getSize to real stat

  - namespace ops on files - why not on wildcards?

  - should callbacks be introduced for some things?  Best on tasks,
    but also for streams (is factory!)  Necessary for
    monitoring/streaming, so best introduce in general...

  - integrate GridRPC / GridCPR / JSDL?  What else?

  - check if bulk operations can be done with task containers
    (explicit support needef for argument list generations?)

  - ACLs 

  - Authorization (call outs?)

  - task = ftf.read (1, buffer, &n);
    task.run ();

    When are 'n' and 'buffer' available?  I would say after wait.

  - default: define semantics, point out parts where semantics is up
    to the implementation    

GGF14:
  - who sends UC doc to editors?

+-------------------------------------------------------------+