5:19 a.m.
Hi all,
As discussed over IRC, I am working on prototyping a framework to
power generic widgets for Fedora. This framework will allow writing
widgets for Fedora in Python, mostly.
Basic components
==============
Dispatcher
----------------
Dispatcher is part of a daemon process which keeps on listening to
fedmsg messages and invoking widgets to save data as needed. Widgets
can be tied to the dispatcher using signals, observer patterns, etc.
Widget
----------
I define a widget implementation as a standalone entity which knows:
1. How to handle raw fedmsg data, format it and save it for enabling
faster query
2. Render data from saved data.
API
------
Provide REST interface to fetch data from a widget for a particular
entity, say, badges info for a user for UserBadgesWidget.
I have started working on a prototype based on the Observer design
pattern here[1].
Please provide your feedback on the same. I am also thinking to work
on a prototype based on signals, to see which prototype allows us to
expose friendly interfaces for writing widgets.
[1]:
https://github.com/rtnpro/fedwidgets/blob/master/fedwidgets/prototypes/ob...
Regards,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6
9:18 a.m.
On Sun, Mar 15, 2015 at 03:49:29PM +0530, Ratnadeep Debnath wrote:
Hi all,
As discussed over IRC, I am working on prototyping a framework to
power generic widgets for Fedora. This framework will allow writing
widgets for Fedora in Python, mostly.
In general, I think this is a cool idea. We expose *lots* of raw
information via datagrepper.. but it's just a pile of data. Providing
someway for people to query for more structured, preprocessed
information could be neat.
Basic components
==============
Dispatcher
----------------
Dispatcher is part of a daemon process which keeps on listening to
fedmsg messages and invoking widgets to save data as needed. Widgets
can be tied to the dispatcher using signals, observer patterns, etc.
Widget
----------
I define a widget implementation as a standalone entity which knows:
1. How to handle raw fedmsg data, format it and save it for enabling
faster query
I really like part (1). We could pre-process all kinds of data. Keep
statistics and make them all available via API.
2. Render data from saved data.
I'm not sure how I feel about part (2). It seems to me like it will
introduce a higher overhead to future changes to the service and more
of the same for people trying to use it.
What if:
- Someone wants to style their widget differently?
- Combine the data from two widgets into some other widget?
- Use only part of the data typically associated with one widget.
To do any of those, would they need to submit a patch to our
server-side code, and then have it be reviewed, released and deployed
before they can make use of it?
How do you feel instead about splitting it up into two pieces:
server-side data denormalization and client side visualization (via a
python lib or maybe better, a js lib?). That way people can query for
the grouped/collated data and then present it however they like. Just
a thought.
API
------
Provide REST interface to fetch data from a widget for a particular
entity, say, badges info for a user for UserBadgesWidget.
I have started working on a prototype based on the Observer design
pattern here[1].
Please provide your feedback on the same. I am also thinking to work
on a prototype based on signals, to see which prototype allows us to
expose friendly interfaces for writing widgets.
[1]:
https://github.com/rtnpro/fedwidgets/blob/master/fedwidgets/prototypes/ob...
Looks like a good start :)
12:04 p.m.
Hi,
On Mon, Mar 16, 2015 at 7:48 PM, Ralph Bean <rbean(a)redhat.com> wrote:
On Sun, Mar 15, 2015 at 03:49:29PM +0530, Ratnadeep Debnath wrote:
I really like part (1). We could pre-process all kinds of data. Keep
statistics and make them all available via API.
> 2. Render data from saved data.
I'm not sure how I feel about part (2). It seems to me like it will
introduce a higher overhead to future changes to the service and more
of the same for people trying to use it.
By rendering data, I meant render JSON data, and html snippets
(pagelets) too. However rendering html snippets would be less
flexible. So, I think, we should just go ahead with rendering JSON
data.
What if:
- Someone wants to style their widget differently?
- Combine the data from two widgets into some other widget?
- Use only part of the data typically associated with one widget.
To do any of those, would they need to submit a patch to our
server-side code, and then have it be reviewed, released and deployed
before they can make use of it?
I agree, +1
How do you feel instead about splitting it up into two pieces:
server-side data denormalization and client side visualization (via a
python lib or maybe better, a js lib?). That way people can query for
the grouped/collated data and then present it however they like. Just
a thought.
That's where the REST API comes into picture :)
Regards,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6
3331
days inactive
3332
days old
infrastructure@lists.fedoraproject.org
2 comments
3 participants
participants (3)
-
Ralph Bean -
Ratnadeep Debnath -
Ratnadeep Debnath