Page "Use Cases for IWC"
stsire
I have started to edit a simple (experimental) page to get some ideas
of what we could do with inter-widget communications. The main
rationale is to have a better understanding of the use cases from a
user's perspective as we are now more and more talking about IWC. The
collected use cases should also help to spot technical requirements
(types of usual events and so on).
The page is at http://groups.google.fr/group/talk-about-widgets/web/use-cases-for-iwc
Feel free to complete it as long as you add some scenarios
Ivan Zuzak
general remote processing and widget composition.
Ivan
On Oct 6, 12:09 pm, stsire <sts...@gmail.com> wrote:
> Dear All,
>
> I have started to edit a simple (experimental) page to get some ideas
> of what we could do with inter-widget communications. The main
> rationale is to have a better understanding of the use cases from a
> user's perspective as we are now more and more talking about IWC. The
> collected use cases should also help to spot technical requirements
> (types of usual events and so on).
>
BCmoney
I'm developing a framework for inter-widget communication based on
Medical Simulations (i.e. pass a Virtual Patient's vital signs from
one simulation software to another, via their widget
representations).
Practical uses can be e-Learning and Medical training, but also user-
focused for Medical Portals.
Ivan Zuzak
( http://geppeto.fer.hr/ ), it might be something very similar.
Geppeto allows you do organize the flow of data through widgets just
by clicking on the widget interfaces.
Ivan
Scott Wilson
What sort of framework is it? We've identified quite a few and have
some dimensions identified, e.g.:
client-side/server-side
single user agent (e.g. only in same browser window)/multiple user
agents (e.g. x-browser, x-session, multi-user etc)
event-driven(Messaging)/user-initiated (D'n'D)
S
> --
>
> You received this message because you are subscribed to the Google
> Groups "Talk about Widgets" group.
> To post to this group, send email to talk-abou...@googlegroups.com
> .
> To unsubscribe from this group, send email to talk-about-widg...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/talk-about-widgets?hl=en
> .
>
>
Ivan Zuzak
composition (Messaging)".
Currently its client-side, single user agent, and has a messaging-
style communication infrastructure, though much of that is invisible
to the users of the platform which use the Geppeto tool to compose
widgets. The users only see the widgets and write programs through
right-click actions on widget interfaces.
E.g. let's say you want to compose a book search widget A and
translate widget B into a new widget C that searches for books and
returns reviews in your language.
In Geppeto you would:
1) add A and B to your widget dashboard
2) add a new "empty" widget to your dashbaord that will become C
3) drag'n'drop GUI elements from A and B to C - the GUI elements will
not carry over any logic, it's only the interface which is needed on C
(since it was empty at start)
4) using right-click actions on GUI elements, you would create the
logic for C which will read the book search query on C, transfer that
query to A, trigger the logic in A to search for books for that query,
copy the reviews of the result from A to B, copy a target language
string from C to B, trigger the logic in B to translate the reviews,
and at last - copy the result of the translation from B to C. This is
the end of the "programming" stage.
5) Use the new widget C by entering a search query, a target language,
and clicking a button which triggers the execution of the proces
defined in 4).
As you can see, the idea behind Geppeto is that it's a general
platform for widget composition. You should check out the Geppeto
homepage for more information and especially http://geppeto.fer.hr/tutorial.html.
Cheers,
Ivan
On Dec 9, 9:58 am, Scott Wilson <scott.bradley.wil...@gmail.com>
wrote:
> 3KViewDownload
BCmoney
offers a good paradigm for inter-widget communication, where each
widget would get its own Topic (or Queue) depending on the nature of
the widget and whether it is single or multi-user and single or multi-
session...
The ActiveMQ JMS chat widget reminds me alot of what can be done with
a unified messaging model for widgets:
http://activemq.apache.org/web-samples.html
Scott Wilson
> Not reinventing the wheel is always a good idea, but perhaps JMS
> offers a good paradigm for inter-widget communication, where each
> widget would get its own Topic (or Queue) depending on the nature of
> the widget and whether it is single or multi-user and single or multi-
> session...
I was thinking a JS API based on the AMQ one[1] would make a lot of sense: basically two methods : send message (topic name, message) and register a callback (topic name, callback fn); I've put a draft feature spec based on this into the Wookie tracker[2].
> The ActiveMQ JMS chat widget reminds me alot of what can be done with
> a unified messaging model for widgets:
> http://activemq.apache.org/web-samples.html
[1] http://activemq.apache.org/ajax.html
[2] https://issues.apache.org/jira/browse/WOOKIE-133