[infod-wg] section 3 comments

[Djaoui, A (Abdeslem)]

Cecile
See </AD> commnets
 
Abdeslem

-----Original Message-----
From: owner-infod-wg at ggf.org [mailto:owner-infod-wg at ggf.org]On Behalf Of Cecile Madsen
Sent: Thursday, September 15, 2005 4:39 PM
To: infod-wg at ggf.org
Cc: Cecile Madsen
Subject: [infod-wg] section 3 comments 



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.uk> 

	09/15/2005 08:08 AM




To

Cecile Madsen/Santa Teresa/IBM at IBMUS, "Fisher, SM \(Steve\)" <S.M.Fisher at rl.ac.uk>, "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 ?!


<AD>

Well it all depends on the exact semantics of createSubscription(). I understood this is a registry operation!  

I am thinking about aligning with WSN. NotificationProducer in WSN supports subscribe() and getCurrentMessage() operations. The management of subscription once they are created is delegated to SubscriptionManager. In WSN the subscription is with ONE known producer that either is also a SubscriptionManager or contacts the subscriptionManager that takes responsibility for the management of the subscription. This should still be allowed in InfoD. What is new in InfoD is the createSubsciption() which is not directed at ONLY one publisher. The registry finds the relevant publishers and in turn it should effectively create a subscriptions with/for each one of them. (THIS ONE OF THE ADDITIONAL FINE GRAINED FUNCTIONALITIES THAT INFOD ADDS TO WSN) Now how do we do this. Up to now we have assumed that the infoD registry (subscriptionregistrationManager) does that somehow. But we could use the subscriptionManager from WSN for the inividual subscriptions if we build on top of WSN.  So our subscriptionManager will extend from WSN subscriptionManager to decouple subscribers from publishers. This is different from saying that createsubscription() is a replacement of subscribe() and our subscriptionManager is a replacement of WSN subscriptionManager.

I mentionned getcurrentmessage() because of its similarity() with getData() and so getData() seems to belong in a publisher interface.

</AD> 
 
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.
 

<AD>

Yes indirectly without saying how? But the spec should clearly state how a subscription creates an event or it shouldn't state that at all. Because if we don't specify it it will result in non-interoperable ways of creating events. I think we need to nail down the operations and semantics of how we define events and messages or remove any reference to that effect from the spec completely.

</AD>  
-> 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...).


<AD>

Well this was really one of main initial driving functionality of InfoD work. May be in GGF we should simply discuss if we really need this in InfoD and if a couple of sentences is enough or we need to define operations to supportr taht functionality in the future.

</AD> 

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). 

<AD>

Yes that defines the structure of messages but this is different from instructing the publisher to publish a certain message as a result of a certain event. This functionality is alluded to in the spec but the spec does not really specify anything about that functionality.

</AD> 

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. 
<AD>

OK I see now that the semantics are different and that's a good justification for a different name. I still fail to see why this is an advanced scenario. As I said before I see this as beloging to an infoD base publisher (as an extension of WSN Producer)

</AD> 
-> To stay in line with your 1st comment, maybe we could rename GetMData to getRegistrationData or getRegistrationEntries ?


<AD>

Yes I am OK with either

</AD> 


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/20050916/56017460/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: ecblank.gif
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20050916/56017460/attachment.gif