[infod-wg] section 3 comments

Thu Sep 15 10:38:52 CDT 2005

Abdeslem,

See my answers below.

Everyone,

I'll update the specs by Wed next week so send me your comments
by then; as mentioned before, I'll update gridforge with the latest draft
'pre-ggf15' version of the specs soon.

Thks,
Cecile

Cecile Madsen
Websphere II Replication,  DB2 II Replication,  DB2 DataPropagator
IBM Silicon Valley Lab
(408) 463 2578
madsen at us.ibm.com
----- Forwarded by Cecile Madsen/Santa Teresa/IBM on 09/15/2005 08:20 AM
-----

             "Djaoui, A                                                    
             \(Abdeslem\)"                                                 
             <A.Djaoui at rl.ac.u                                          To 
             k>                        Cecile Madsen/Santa                 
                                       Teresa/IBM at IBMUS, "Fisher, SM       
             09/15/2005 08:08          \(Steve\)" <S.M.Fisher at rl.ac.uk>,   
             AM                        "Dieter Gawlick"                    
                                       <dieter.gawlick at oracle.com>,        
                                       "Shailendra Mishra"                 
                                       <shailendra.mishra at oracle.com>, "SC 
                                       Davey" <skiing_davey at yahoo.co.uk>,  
                                       Susan Malaika/Santa                 
                                       Teresa/IBM at IBMUS, Vijay             
                                       Dialani/Almaden/IBM at IBMUS           
                                                                        cc 

                                                                   Subject 
                                       FW: new draft for section 3         

Now after reading section here are my immediate thoughts
1- The names BaseXManager should be changed to BaseXRegistrationManager
(e.g. BasePublisherRegistrationManager). This is because the Manger is not
managing the Xs but just their registration.
      -> OK no problem

2- The Consume interface should simply be called the Consumer interface.
      -> You're right. That is what we had decided (!) so an oversight on
my part.

3- We need a Publisher interface that will optionally support a subscribe()
message (similar to WSN)  (we need more discussion here)
      -> How about the Publisher simply implement the SubscriptionManager
interface ? then it will get the subscribe operation, ie
          the CreateSubscription... ?  isn't that good enough ?!

    and for "ADVANCED" publishers select/defineEvent()
      -> This is again provided indirectly thru a CreateSubscription: a
subscription can create an event...
          The current specs mention it.  We could however split that
overloaded function from the CreateSubscription and render that
          operation more like the subscribe and rely on a different one
like CreateEvent to deliver the event creation.
      -> I see this as an exercise to get aligned with WSN.  But wouldn't
bring it up at our GGF F2F because it is talking about
          advanced functions that should be relegated to the 'other' doc
(that is not yet created...).

    and select or define Message() (we already had some discussion on this
Pluggins remember?
    but I don't know if a final decision was reached).
      -> can you expand on this ? I don't remember the context.  The define
Message() as you mean it is probably
          now delivered by the user data vocabulary, which essentially
defines a message structure (so RegisterVocabulary operation).

4- change getMdata to getMetaData(), although I am struggling with the use
of the word metadata. We are talking here about getting the the data of the
entries in the RegistrationManager. How about getEntries(). Somebody remind
me why this is different from GetDataForBrowse()
      -> get data for browse is a pull point operation, ie consumer data
whereas getMetadata is a registry operation so we thought it'd be cleaner
to
          separate both from an interface pespective: the getdata may be
part of a 'advanced' scenario whereas all infod (base) scenarios will need
the
          getMetadata.
      -> To stay in line with your 1st comment, maybe we could rename
GetMData to getRegistrationData or getRegistrationEntries ?

Abdeslem

-----Original Message-----
From: Djaoui, A (Abdeslem)
Sent: Thursday, September 15, 2005 2:33 PM
To: 'Cecile Madsen'; Fisher, SM (Steve); Dieter Gawlick; Shailendra Mishra;
SC Davey; Susan Malaika; Vijay Dialani
Subject: RE: new draft for section 3

Well done Cecile and thanks for the enormous effort you put in.
Just a comment for now: In order to decide about the best way of splitting
the spec, we should think about what fine-grained functionalities are
provided by infoD, not so much what patterns can be supported although
there is a link. Usage patterns are defined through various combinations
and constraints of the basic functionalities (called Profiles). As I said
before we need to nail down the additional functionality that InfoD adds to
WSN if we are going to make a sound decision on the splitting - so here is
a topics for discussion up to GGF15.

Abdeslem
      -----Original Message-----
      From: Cecile Madsen [mailto:madsen at us.ibm.com]
      Sent: Wednesday, September 14, 2005 5:51 AM
      To: Fisher, SM (Steve); Dieter Gawlick; Shailendra Mishra; SC Davey;
      Susan Malaika; Vijay Dialani; Djaoui, A (Abdeslem)
      Subject: new draft for section 3

      Hi everyone,

      As mentioned in the last INFOD call, the best way to prep
      for GGF15 discussions, as far as section 3 is concerned, is to
      simply reorg that section to enable a clear alignment with wsn.

      Here's a first cut at that work. Note that there is no new content
      and no trying to address the wsn interaction with infod; so
      there is still some <todo> statements. I also highlighted in blue
      discussion topics for GGF15 as I doubt we'll go over them
      beforehand.

      This was a rather tedious and long exercise in reshaping
      that section to define all of the base infod managers (a la
      subscription
      manager). It also moves the discussion of ws resources to the end.

      I haven't updated gridforge with this as the base for that work was
      version 8 and gridforge shows a version 9 so updates have been
      made since then to other sections. When you review the doc below,
      simply concentrate on section 3 for now (although I also updated
      the reference section...) I'll figure out later how to consolidate
      these
      changes in gridforge.

      FYI: this is our 'base infod specs' doc, ie doesn't include any
      advanced functions of getdata, disseminator, pobox...

      (See attached file:
      INFOD_Interfaces-draft-version8.base.preGGF15.doc)

      I hope that this will help to prep GGF15 discussion
      as I will most likely *not* be able to attend in person...

      Thks,
      Cecile

      Cecile Madsen
      Websphere II Replication, DB2 II Replication, DB2 DataPropagator
      IBM Silicon Valley Lab
      (408) 463 2578
      madsen at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20050915/4b256fc0/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic20143.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20050915/4b256fc0/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20050915/4b256fc0/attachment-0001.gif 