[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