Component Integration
Tylor Sherman
I have made a number of improvements to our component and I still have
a few questions. My first, and biggest one, is could you explain what
you expect for a component to fulfill its integration requirements?
Re-reading through the documents "Communicating Components Framework"
and "Muse III Platform Description" I see functional descriptions on
how each component authenticates and how to subscribe/unsubscribe, but
I don't see a central definition of what it means to be an intregrated
component.
Could you point me to something specific that I may have missed or
could you succinctly explain this for me?
In an earlier email you indicated that "it’s far from obvious what
problem this component is solving" ("RE: Usability Issues", July 17,
2008). How much of this should be documented on the component page? I
had viewed the provided description in the XML file as the main
description (useful when someone is browsing the component
'catalogue') and that the component page should only provide its
functionality.
At this point it seems our component is properly authenticating with
the Mobile Muse platform and from there users can create a channel,
add custom tags or RSS feeds, and get back an RSS feed of their
aggregated items and SMS messages. There is a link to automatically
log in to Sifttool.com where more advanced (and more technical) admin
options are available.
Thanks in advance,
Tylor
Jim Udall
requirements' and there is a long answer. I will tell you the short answer
but then advise you that for Raincity, the long answer it more appropriate.
The short answer:
A component is successfully integrated into the MUSE platform component
framework if it minimally satisfies the requirement of having an IFRAMEurl
that successfully displays and behaves when invoked from the Platform
website. In addition, it must also successfully respond to the REST
requests to subscribe and unsubscribe.
That's the short answer.
The long answer is more complicated. In addition to the preceding
statement, successful integration requires the following attributes:
1. The design and implementation of the component must be re-entrant and
support the instantiation of that component across multiple users - each
supporting their own namespace. That namespace must also support resources
within the MUSE platform that are unique to that user. Specifically Service
Points within the platform are local to a user. Hence any use of Service
Points by a platform MUST use the Service Points local to the user
instantiating the component. For your component as an example, you use a
Service Point to handle inbound SMS. That Service Point cannot be fixed and
dedicated to you (i.e. raincity - the platform user account holder), but
rather the Service Point associated with the user instantiating your
component. (not to imply you are not doing the correct thing already btw -
since I belive you are doing this correctly)
2. A component MAY also present a REST interface (above and beyond the
subscribe/unsubscribe methods) that other platform components can use to
manage and leverage that component. I believe that is the intent of your
SIFTtool component. As such successful integration of your component will
depend on the requirements as specified and negotiated with the client
components that wish to use your component. As a platform administrator, I
cannot tell you specifically what those requirements are however.
3. Similarly, a component may also require the services of another server
component - that has implemented a RESTful communication method. I don't
think this is the case for your SIFTtool. But in principle, the component
will be fully integrated when it has subscribed to the published REST
implementation of its server component.
4. Understand that the components that we - MUSE - are paying for are
intended to address specific needs for our development community. As such
there are requirements that we will apply to ensure the delivered components
are of sufficient flexibility and capability to satisfy our development
community. Hence it is the right and duty of the MUSE management team to
negotiate and describe acceptable service level implementation of any
component. That's a long winded way of saying I think we have to sit down
with you to discuss the particular implementation of your SIFTtool
component. You're current implementation is much better than before.
However there are some things we need to discuss. The biggest problem I
have with your current implementation is the rather bizarre notion of
sometimes you click on something and it asks me to log in. I would say this
is an unacceptable implementation - given that I'm already logged in via
MUSE. However we should go over your implementation in detail to discuss
changes and adjustments we would like to see.
Jim
Boris Mann
On 11-Aug-08, at 10:07 AM, Jim Udall wrote:
> You're current implementation is much better than before.
> However there are some things we need to discuss. The biggest
> problem I
> have with your current implementation is the rather bizarre notion of
> sometimes you click on something and it asks me to log in. I would
> say this
> is an unacceptable implementation - given that I'm already logged in
> via
> MUSE. However we should go over your implementation in detail to
> discuss
> changes and adjustments we would like to see.
Sorry, but I brought this up months ago. Unless we have a unified
user / pass / token system, we have no choice but to maintain external
accounts for extended, integrated features. These SAME features can be
handled remotely through the REST interface.
It's clear that items that do require a separate login should either
login seamlessly into the SIFTtool account, or be marked as advanced
features that aren't visible / available through the MUSE interface.
We're sitting down tomorrow morning to review, other thoughts welcomed.
Cheers,
--
Boris Mann
Office 604-682-2889
Global 916-341-9528
skype: borismann
Boris Mann
On 11-Aug-08, at 10:43 AM, Boris Mann wrote:
>
> On 11-Aug-08, at 10:07 AM, Jim Udall wrote:
>
>
>> You're current implementation is much better than before.
>> However there are some things we need to discuss. The biggest
>> problem I
>> have with your current implementation is the rather bizarre notion of
>> sometimes you click on something and it asks me to log in. I would
>> say this
>> is an unacceptable implementation - given that I'm already logged
>> in via
>> MUSE. However we should go over your implementation in detail to
>> discuss
>> changes and adjustments we would like to see.
>
> Sorry, but I brought this up months ago. Unless we have a unified
> user / pass / token system, we have no choice but to maintain
> external accounts for extended, integrated features. These SAME
> features can be handled remotely through the REST interface.
>
> It's clear that items that do require a separate login should either
> login seamlessly into the SIFTtool account, or be marked as advanced
> features that aren't visible / available through the MUSE interface.
OK, there was one link in the component interface that lead to a non-
logged in version. We've modified the rest of the links to enable
seamless logins. We'll also be adding some explanation to our
component page, that will link to further documentation on SIFTTool.com.
Right now you can login to developers.mobilemuse.ca, select the SIFT
Tool Aggregator component, and create channels which will start
aggregating content and immediately enable receipt of SMS messages
tagged with #codes.
I'd appreciate it if people with developer logins could test the
component interface, and let us know if there is anything that needs
more explanation (note: changes from our review today won't be in
place for another day or so, but everyone will continue working).
Jim Udall
stuff appears. However, If I try it as me (i.e. judall), I still get all
the login stuff
As for other users trying it...
Subscription is currently an admin process. I.e. it is not possible from
the web site to self-subscribe. All parties who wish to test this, please
send me an e-mail and I will subscribe you to the SIFTtool
Jim
Tylor Sherman
user accounts (on our side) a while ago and that is causing problems.
I've removed both of your channels, if you try again this should be
fine.
Tylor