[deepamehta-devel] usecases

Jörn Weißenborn joern.weissenborn at gmail.com
Mi Sep 11 21:47:21 CEST 2013


Hi,

here a simple sketch of usecase cases. Please don't take it to serious,
just ideas...

After each solution a name is written. This does mean that in case of "jri"
it would be jris job, in case its not jri the name is a suggestion.

Usecase 1

Problem:

I am an experienced programer and I design my new app (either webapp or
plain old desktop or sever). I find the webclient neat but of no use for
me. Most of the other modules are as well. wWhat I what I want, is a simple
deepa-mehta core. I most likely don't know, understand or like OSGi. I want
an instance. Just let me instanciate DM and give me an nice interface.

Possible Solution:

- define low-level DM API:(JRI)

    What does DM offer you which no other tool/library offers? German:
Schuster bleib bei deinen Leisten!"

- create generic bridge class which enables a module to break out if the
application: (jri)
    it should provide hookups as easy as overriding a specific "onThat"
method and also provide predefiend functions. You must not learn any OSGI
to write your bride

- create zmq based bridge together with a simple endpoint.(joern)
    this endpoint works like 2 sub/pub channels, an upstream and
downstream. the interface now provides methods to call specific DM
functions and to look for events or changes of the state of the DM engine.
this way you can can work asynchrone with DM



Usecase 2:

Unlike the user of scenario one I have only a simple (web)application. I
don't need your webmodule or your rendereres, I just want a kind of core-dm
with several options to decide if I want for example websocket bindings or
rest binding. I May develop a pure desktop app, so a ZeroMQ binding would
come in handy.

Possible Solution:

- use bridge from usecase 1

- create a websocket bridge (joern)

- refactor DM REST service to bridge model(?)

Usecase 3:

I don't know anything about programming. I can write html and know some
basic javascript, but not more then eventhandling... I would like to simply
give my topic types a kind of ID and a html/css which contains all the info
needed to render this topic.

Possible solution:

- take ember.js (or whatever) + twitter bootstrap and create a cool mockup
with static data(?)
    static data will be supplied by rest or websockets. we take of that
later

- alternative: throw away the webmodule and create a new modern mvc with an
asynchrone bridge from Usecase 2, importand for pushing stuff ->
collaboration!
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.deepamehta.de/mailman/private/devel-lists.deepamehta.de/attachments/20130911/00a9989a/attachment.html>


Mehr Informationen über die Mailingliste devel