[OpenAjaxInterop] Minutes 2008-12-08

Howard Weingram weingram at tibco.com
Wed Dec 10 18:16:20 PST 2008


Heh!

Thanks, Jon.

Regards,
Howard


On 12/10/08 5:04 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> Hi Howard,
> Regarding "You meant onComplete...", I have updated the minutes and one of the
> wiki pages with corrections.
> 
> Regarding "OpenAjax.hub.Hub" and following Java capitalization conventions,
> and the benefits of having a SHORT name, that's good enough of an explanation
> for me. :-)
> 
> Jon
> 
> 
> 
> 
> Howard Weingram <weingram at tibco.com>
> 
> 
>>>>> Howard Weingram <weingram at tibco.com> 12/09/2008 12:42 AM
> 
> To 
> 
> Jon Ferraiolo/Menlo Park/IBM at IBMUS, <interop at openajax.org>
> 
> cc 
> 
> 
> Subject 
> 
> Re: [OpenAjaxInterop] Minutes 2008-12-08
> 
> Hello everyone.
> 
> I am including comments below.
> 
> The "wiki page" that I reference below is, for your convenience:
> 
> http://www.openajax.org/member/wiki/Hub_1.1_Proposal_Nov_2008
> 
> 
> On 12/8/08 12:21 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:
> 
>> > Interoperability Minutes 2008-12-08
>> > 
>> > URL: 
>> http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08
>> > <http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08>
> ...
> 
>> > 
>> > subscriberData
> ...
>> > RESOLUTION: Include subscriberData
> 
> Committed in OpenAjax-mashup.js
> Wiki page updated
> 
>> > unsubscribe onDone
> ...
>> > RESOLUTION: Include subscriberData
> 
> You meant onComplete here, not subscriberData.
> 
> Note: I changed the parameter name from onDone to onComplete because when a
> reader skims over documentation, onDone and onData look quite similar and
> this may lead to unnecessary bugs due to transposition of these parameters.
> 
> Committed in OpenAjax-mashup.js
> Wiki page updated
> 
>> > getParameters 
>> > 
>> > Jon: I wasn't sure about this one. Need to talk to Howard. Is this just a
>> > manager-side feature or is there use on the client also?
>> > 
>> > Javier: I wasn't sure either. I'll check emails. Maybe can be moved up from
>> > base to Managed Hub.
>> > 
>> > (will keep this open until we can talk to Howard)
> 
> I have responded to Javier's query, but this is still open for discussion.
> 
>> > sendEvent subscriptionId
> ...
>> > RESOLUTION: Add subscriptionId
> 
> Committed in OpenAjax-mashup.js
> Wiki page updated
> 
>> > subscribe/publish callbacks
> ...
>> > Jon: Next item was whether we needed a NotAllowed.
> ...
>> > RESOLUTION: Add NotAllowed
> 
> API committed in OpenAjax-mashup.js for subscribe()
> Wiki page updated for subscribe()
> 
> More comments about NotAllowed & publish() later.
> 
>> > Jon: Next item is multiple versus single callbacks
> ...
>> > RESOLUTION: Accept Howard's proposal for separate security callback
> 
> API committed in OpenAjax-mashup.js
> Wiki page updated
> 
>> > Jon: On a tangent issue, should client even find out about being denied
>> > permission? My feeling is yes. There is an argument that any information to
>> > malicious components is bad, but in this case, either we are sandboxing or
>> we
>> > aren't. OK to tell components they were denied, but don't provide any
>> details.
> 
> On subscribe, this is easy and makes a lot of sense.
> 
> On publish, it turns out that this is a lot more problematic. There are 2
> serious issues.
> 
> 1. The onPublish callback does not actually prevent a publish. It
>     prevents individual subscribers from receiving the published
>     data. So a single publish() may be both successful and
>     unsuccessful.
> 
>     Possible resolution: NotAllowed indicates that perfectly
>     legitimate subscribers (which were allowed to subscribe to
>     topic T by onSubscribe) were prevented by onPublish from
>     receiving a message published on topic T.
> 
>     If we adopt this approach, then publishForClient throws
>     NotAllowed if onPublish returns false for even one of the
>     subscriptions, and HubClient notifies the client code of
>     the failure.
> 
> 2. If the HubClient notifies the client application that a
>     publish attempt was NotAllowed, then the client
>     application probably needs to determine which publish
>     failed. Is the information contained in the warning
>     sufficient to identify the culprit?
> 
>     Some possible approaches:
> 
>     a. Hub.publish should return a handle or token that can
>         be provided in the onWarning callback, to associate
>         the callback with a specific publish.
>     b. NAK returns topic and data that were published, and
>         the onWarning callback includes topic and data in
>         this case.
>     c. Provide an onComplete callback for publish.
>     d. Punt. Don't try to match callbacks to publishes. Client
>         just gets a generic error saying that some publish was
>         NotAllowed.
>     e. Eliminate all notification of NotAllowed for publish
>     f. Eliminate all notification of NotAllowed for subscribe
>         as well as for publish.
>     
> If we were to do (f), then the HubClient does not tell the client anything.
> Any given publish or subscribe could fail silently. If a client needs to
> know about failures, this must be implemented at a higher level (ugly,
> probably redundant). Silent failures in infrastructure code can have very
> unpleasant consequences.
> 
> ...
>  
>> > Property naming conventions
> ...
>> > RESOLUTION: Accept Howard's proposal for property naming conventions
> 
> Committed in OpenAjax-mashup.js
> 
>> > onPublish, onSubscribe as required
> ...
>> > RESOLUTION: Accept Howard's proposal for requiring onPublish, onSubscribe
> 
> Committed in OpenAjax-mashup.js
> Wiki page updated
> 
>> > OpenAjax.js inside of OpenAjax-mashup.js
>> > 
>> > Jon: It looks like Howard has included logic and APIs for Hub 1.0 within
>> > OpenAjax-mashup.js.
> 
> Yes. 
> 
>> > Jon: I'm OK with that as a short-term developer expediency, but before we
>> go
>> > final, we need to find a way to have a small footprint version that people
>> can
>> > use when they only need Hub 1.0 functionality. Maybe separate back out the
>> > OpenAjax.js file or duplicate the logic where a developer can either use
>> > OpenAjax.js or OpenAjax-mashup.js.
> ...
>> > RESOLUTION: We need to find a way to allow developers to use Hub 1.0
>> > functionality with small footprint and not force everyone to include
>> > OpenAjax-mashup.js
> 
> I agree that we should also have a small-footprint version.
> 
> Let's look at which of these approaches works best once we are done tweaking
> the interfaces. 
> 
>> > OpenAjax.hub.Hub
>> > 
>> > Jon: This is confusing. Why hub.hub? Why is one lowercase and the other
>> > uppercase? Can we find a different name for the 3rd part?
> 
> For those familiar with Java packages, I used a package-like notation as an
> organizational principle. OpenAjax.hub corresponds to the "package".
> OpenAjax.hub.Hub is the "interface". Package names in Java are lowercased
> (I'm excepting OpenAjax from this), whereas class and interface names are
> typically upper-camel-cased and actual functions are lower-camel-cased.
> Thus, "OpenAjax.hub.ManagedHub.subscribeForClient()".
> 
> This distinction allows us to group our classes, interfaces and functions in
> an orderly way:
> 
> * OpenAjax.hub.ManagedHub ("class"),
> * OpenAjax.hub.SubscriptionHandle ("class", well, just an opaque handle)
> * OpenAjax.hub.HubClient (an "interface")
> * OpenAjax.hub.Container ("interface")
> * OpenAjax.hub.Hub ("interface")
> * We still have OpenAjax.hub.subscribe, etc. but I'm happy to
>     leave them exactly as they are.
> 
> Again, I am using this naming structure as an organizational principle. I
> don't want to carry it "too far". JavaScript is not Java. However, this
> seems to work pretty well.
> 
>> > Javier: I believe no one implements OpenAjax.hub.Hub. It's just interfaces
>> > that are implemented by ManagedHub and ClientHub. We could call it
>> > HubInterface or HubIFace.
> 
> That's fine too. However, I like Hub because it's SHORT. Also, if we're
> going to name anything "FooInterface" then we should name all of the
> interfaces as interfaces (HubInterface, ContainerInterface and
> HubClientInterface). I think what we have now is clearer.
> 
> OpenAjax.hub.Hub is simply an interface. It is "extended" by
> OpenAjax.hub.ManagedHub and OpenAjax.hub.HubClient. I included
> OpenAjax.hub.Hub in the proposed interface definition in order to force us
> to maintain a degree of consistency between ManagedHub and HubClient. This
> allows some application or toolkit code to be written without regard for
> whether the toolkit code is supposed to run on the manager side or the
> client side; something hands the toolkit a Hub instance, be it a HubClient
> instance or a ManagedHub instance, and the toolkit uses that Hub instance to
> pub and sub. 
> 
> Hub *never* gets instantiated. We can remove the actual Hub function from
> the reference implementation. We may want to leave it in the documentation
> in order to show that application code really should be able to treat a
> ManagedHub like a HubClient in terms of certain functions.
> 
> ...
>> > Jon: Not a critical issue at all. Whatever we decide isn't that important
>> one
>> > way or the other.
> 
> Exactly.
> 
>> > Moving Hub 1.1 branch to mainline, updating Hub 1.1 spec
>> > 
>> > Jon: Should we move the Hub 1.1 branch with the new APIs to mainline?
>> > 
>> > Javier: Not yet. Still need to work on smash provider. Let's talk about it
>> > next week. 
>> > 
>> > Jon: Change the Hub 1.1 spec now? I'm interested in updating the Hub 1.1
>> spec
>> > ASAP to reflect our most current thinking. What's there now is out of date.
>> > 
>> > Javier: Best to wait one more week.
>> > 
>> > Jon: OK. 
> 
> I agree. 
> 
> Thanks for all of your work, feedback & input!
> 
> Best Regards,
> Howard
> 
> --
> Howard Weingram      650.846.1000
> Principal Architect  TIBCO Software Inc.
> 
> TIBCO PageBus(TM) delivers ultra-lightweight
> publish-subscribe messaging for mash-ups.
> Learn more at http://www.pagebus.org
> 
> 
> 
> 
> 
> 
> --
> Howard Weingram      650.846.1000
> Principal Architect  TIBCO Software Inc.
> 
> TIBCO PageBus(TM) delivers ultra-lightweight
> publish-subscribe messaging for mash-ups.
> Learn more at http://www.pagebus.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0009.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0010.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0011.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0012.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0013.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0014.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0015.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0016.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/caedbcb2/attachment-0017.gif 


More information about the interop mailing list