- moksha - Fedora mailing-lists

FComm Updates
by John (J5) Palmieri 12 May '09

12 May '09

* No Data Indicator - https://fedorahosted.org/fedoracommunity/ticket/64 - Went one step further and added conditionals to the grid controls so we can display different controls (including info-display controls) depending on the state of the grid. The builds grid has examples of this which show different messages and controls based on if there is no data, only one page of data, multiple pages of data. I still need to go through each of the grids and clean them up * Missing titles - https://fedorahosted.org/fedoracommunity/ticket/73 - a little more time consuming than it seems at first glance but now all of the listed pages have the correct titles being displayed Other Work: While I was modifying the grid I added a defer method to moksha.js and had the grid use this when inserting rows so it doesn't block the UI for long periods of time when processing incoming data. I also did some other performance tuneups. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Various updates
by Luke Macken 12 May '09

12 May '09

Hey guys, Here is what I was up to yesterday... - Fixed bugzilla sorting issue (#202) - Removed transifex link from drop-down hover menus (until we can figure out a way to query it to see what modules it contains) - Increased the FAS visit timeout from 20 seconds to 15 minutes. The FAS visit cookie times out after 20 minutes, so hopefully this optimization should not yield any negative side effects. Speak up if it does - Closed #171, as Updates > All Packages now works (after fixing a uuid issue in Moksha's ConfigWrapper) - Did a lot of Moksha Middleware refactoring, and fixed a fundamental problem with the request flow through to the connectors/extension points. Before, app/widget requests would go: Request -> MokshaMiddleware -> MokshaAppDispatcher -> RootController -> AppController -> App Yet the connector/extension requests looked like this:: Request -> MokshaMiddleware -> MokshaExtensionPoint/Connector Middleware It would bypass the MokshaAppDispatcher(PylonsApp), which handled setting up a lot of useful StackedObjectProxy globals, such as the cache, and the request objects. I made all extension/connector requests go through the MokshaAppDispatcher, which resolves this issue. This also allows Connectors to connect to other connectors, as well as use the global cache (instead of instantiating their own). - I started to try and track down an odd TG2/repoze.who regression with regard to our CSRF test cases. You can reproduce this issue by running `nosetests` in Moksha, but the basic problem is that hitting a secure controller used to yield a 302 (Redirect), but now explodes with a 401 (Forbidden). By "explodes", I mean something is returning a response of u'401 Forbidden...', and the ToscaWidgets middleware then tries to inject resources into it, thus throwing a traceback. So, we need to figure out how this is different from the default TG2 quickstart (which actually works, and does return a 401 as well). Somewhere along the egress, something seems to be handling the 401, and sending up a redirect to the login handler before it gets to the TW middleware... I'm not sure what though.

1 0

FComm update
by John (J5) Palmieri 08 May '09

08 May '09

Bugs I have closed out or otherwise modified: * Don't display pagination controls - https://fedorahosted.org/fedoracommunity/ticket/66 * Builds showing your builds on another user's page - https://fedorahosted.org/fedoracommunity/ticket/224 * "View More" links too generic - https://fedorahosted.org/fedoracommunity/ticket/161#comment:3 - I should note that this is not "done" in that we still need to add the links using the new method to the template - however this bug is no longer relevant as it is a different type of bug now * s/package maintenance tools/maintenance tools for package details nav - https://fedorahosted.org/fedoracommunity/ticket/160 * quicklinks/tasks right side widget missing search tasks - https://fedorahosted.org/fedoracommunity/ticket/158 * s/quicklinks/tasks - https://fedorahosted.org/fedoracommunity/ticket/157 - make sure I didn't miss any * builds grid missing status label - https://fedorahosted.org/fedoracommunity/ticket/154 * user profile right sidebar panels are missing the "panel" class - https://fedorahosted.org/fedoracommunity/ticket/145 * middle click links - https://fedorahosted.org/fedoracommunity/ticket/138 - this was done a week ago but never closed * search box text should be deleted - https://fedorahosted.org/fedoracommunity/ticket/125 - fixed awhile ago but not closed - note I only delete the default text * csrf token munging search string - https://fedorahosted.org/fedoracommunity/ticket/105 - fixed awhile ago Modified: * Show IRC Network - https://fedorahosted.org/fedoracommunity/ticket/170 - this field is not in the database * right sidebar widgets don't show counts yet - https://fedorahosted.org/fedoracommunity/ticket/159 - my packages does this now and any grid app can do this easily (provided the data is sent by the connector). Still need a solution for non-grid apps Fixed but doesn't have a bug (or I just looked over it): FComm now works in webkit based browsers and Opera (though Opera's colors are messed up) -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Cache audit
by Luke Macken 07 May '09

07 May '09

Earlier this week I went through and audited all of our caches. Many were inconsistent and/or incorrect. Here is what we are currently caching, as well as the expire time: Planet user details (rss/face) 24 hours FAS user info 5 minutes FAS who "keep alive" 20 seconds (I think we can safely increase this to < 20 minutes. I will do some testing and find out). Pkgdb Collections table 6 hours PkgDB Package data 1 hour Today's alerts 5 minutes This week's alerts 1 day User's alerts 1 hour Things we should probably look into caching: Bugzilla's for a given package (this cause our cache to grow too much) Bodhi updates ...

1 0

Invasive changes to the Grid
by John (J5) Palmieri 04 May '09

04 May '09

So I have been hacking on the Grid and came up with a flexable way of supporting control ui elements which breaks all of the grid's pagination, info and more links. We need to go through all of the grids and fix them to support the new API. The API consists of JavaScript plugins (pagers, more link and filters are written) which are tied to HTML id's. This allows you to place the control using the mako template. Rather than explain it I will step through the current builds table template: <div class="list header-list"> <div id="grid-controls"> <form> % if tmpl_context.auth('not_anonymous()'): <div id="filter" class="grid_filter" name="owner_filter"> <label for="owner">Display:</label><select name="username"> <option selected="selected" value="${tmpl_context.identity['person']['username']}">Builds I Own</option> <option value="">All Builds</option> </select> </div> % endif </form> </div> <table id="${id}">  </table> <div id="grid-controls"> <div class="message template" id="info_display" > Viewing @{visible_rows} of @{total_rows} builds. </div> <div class="pager" id="pager" type="numeric" ></div> <div class="pager template" id="pager" type="more_link"> <a href="@{more_link}" moksha_url="dynamic">View more builds ></a> </div> </div> </div> All controls are nested in a div with an id of "grid-controls". You can have as many of these divs as you want. Any div inside with an id that matches a plugin name gets processed. Lets start with the filter plugin: <div id="filter" class="grid_filter" name="owner_filter"> <label for="owner">Display:</label> <select name="username"> <option selected="selected" value="${tmpl_context.identity['person']['username']}">Builds I Own</option> <option value="">All Builds</option> </select> </div> You will notice that the div has an id of "filter" which pairs it to the filter plugin (the class and name are there for users defined css and javascript). When the grid is created the filter plugin looks for any select or input elements inside of the div. It then adds an onChange handler and updates the grid's filters to reflect the default values (in this case when I am logged in filters["username"] = "johnp"). The onChange handler automatically changes the filter and tells the grid to refresh its data. In other words, as long as you match up the form control's name to a corresponding filter in the connector, it will automatically do the right thing. Now lets look at the info display: <div class="message template" id="info_display" > Viewing @{visible_rows} of @{total_rows} builds. </div> Notice that it has template as a class and matches up to the 'info_display' plugin. The template class is needed so the template itself doesn't get shown (we have a css def to set display=none) and to also prevent link rewriting. Variables you can use in the info_display template are anything in the grid's options dictionary. This get updated any time the grid refreshes its data. Also notice that this solves the issue of making the info display more relevant to the data (instead of just saying "viewing x of y items" we let the user know they are viewing builds). If we take a look at the next control we see an empty pager: <div class="pager" id="pager" type="numeric" ></div> Pagers have sub plugins that are specified by type. In this case we want a "numeric" pager. You can also request an "alpha" pager or "more_link" pager which is the next element. The numeric and alpha pagers are still generated via code. Right now there are options you pass in to the grid constructor where you can specify alpha, numeric and more pager's but only have them display if the option is set. These options are numericPager=true, alphaPager=true and more_link = <the actual link>. I'm leaning toward having the template itself control this (like we do with the filters above). The more_link pager is slightly different from the others: <div class="pager template" id="pager" type="more_link"> <a href="@{more_link}" moksha_url="dynamic">View more builds ></a> </div> This works much like the info_display plugin and the truth is they can most likely be merged. These changes need to be reflected in all of the tables as they no longer automatically get pagers and links. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Mockup Comparison Report #3: Package Details
by Máirín Duffy 04 May '09

04 May '09

Here it is! It's on the wiki too: https://fedoraproject.org/wiki/FedoraCommunity/UIReview29Apr2009 Next up will be search & people. ~m = Package Details = == General == # s/package maintenance tools/maintenance tools ## ticket 160 https://fedorahosted.org/fedoracommunity/ticket/160 == Package Details > Package > Overview == # "Latest Rawhide Build" and "Owners" bubbles need to be themed ## ticket 148 https://fedorahosted.org/fedoracommunity/ticket/148 # Active Releases overview doesn't match mockup ## ticket 189 https://fedorahosted.org/fedoracommunity/ticket/189 # Author names in changelog are not links. Is this possible to do? ## ticket 190 https://fedorahosted.org/fedoracommunity/ticket/190 # s/package links/dashboard for package details overview ## ticket 191 https://fedorahosted.org/fedoracommunity/ticket/191 # s/view more/view more changelog entries ## previous ticket 161 https://fedorahosted.org/fedoracommunity/ticket/161 # upstream summary still needs to be implemented (future milestone) ## ticket 192 https://fedorahosted.org/fedoracommunity/ticket/192 == Package Details > Package Details > Downloads == # "release" dropdown: s/Fedora devel/Rawhide ## ticket 193 https://fedorahosted.org/fedoracommunity/ticket/193 # "release" dropdown: rawhide should be listed first, other versions in descending numerical order ## ticket 194 https://fedorahosted.org/fedoracommunity/ticket/194 # missing search filter ## previous ticket 184 https://fedorahosted.org/fedoracommunity/ticket/184 # spec file doesn't have file size ## ticket 195 https://fedorahosted.org/fedoracommunity/ticket/195 # file sizes need to be styled (light & italic & small) ## ticket 196 https://fedorahosted.org/fedoracommunity/ticket/196 # order of arches - x86_64 should be listed 2nd ## ticket 197 https://fedorahosted.org/fedoracommunity/ticket/197 # enhancement: allow all to be downloaded at once (checkbox download bundling) ## ticket 198 https://fedorahosted.org/fedoracommunity/ticket/198 == Package Details > Package Details > Maintainers == # why is there a type column? there should be a table for users and a table for groups. ## ticket 121 https://fedorahosted.org/fedoracommunity/ticket/121 # release dropdown missing and search filter missing ## previous ticket 184 https://fedorahosted.org/fedoracommunity/ticket/184 # page title missing ## previous ticket 73 https://fedorahosted.org/fedoracommunity/ticket/73 == Package Details > Package Details > Owners == # owners page should list owner per release, even if the same for every release ## ticket 122 https://fedorahosted.org/fedoracommunity/ticket/122 == Package Details > Package Details > Watchers == # wrong columns: remove type column, roles column is redundant ## ticket 200 https://fedorahosted.org/fedoracommunity/ticket/200 # become a $PACKAGE watcher box not implemented ## ticket 199 https://fedorahosted.org/fedoracommunity/ticket/199 == Package Details > Package Details > Bugs == # Recently-filed bugs are not recent. They are in ascending numerical order (should at least be descending numerical order.) ## ticket 202 https://fedorahosted.org/fedoracommunity/ticket/202 # need to decrease font size on bugs boxes to 2.4 em. kernel has 10000+ closed bugs so it busts out of box otherwise. ## fixed in commit 5fbf18822bee6da5f847679bcab19dc2026acc58 # page 10 of kernel > recent bugs will not load ## ticket 203 https://fedorahosted.org/fedoracommunity/ticket/203 # open assigned bug missing from autofs (bug 427224) ## ticket 204 https://fedorahosted.org/fedoracommunity/ticket/204 # are security bugs handled as in mockup? (could not find examples because of two bugs above) ## ?? # instead of bugs i modified recently can we do bugs for this package that i commented on? i know we can do this search. ## ticket 205 https://fedorahosted.org/fedoracommunity/ticket/205 == Package Details > Maintenance Tools > Builds == # broken image ref: /images/16_build_state_4.png in status column ## ticket 212 https://fedorahosted.org/fedoracommunity/ticket/212 # failed builds not highlighted in red as in mockup ## ticket 211 https://fedorahosted.org/fedoracommunity/ticket/211 # changelog dropdown widget should be implemented ## ticket 210 https://fedorahosted.org/fedoracommunity/ticket/210 # build time column - take out ## ticket 209 https://fedorahosted.org/fedoracommunity/ticket/209 # swap finished and built by columns ## ticket 208 https://fedorahosted.org/fedoracommunity/ticket/208 # state column should be first column ## ticket 207 https://fedorahosted.org/fedoracommunity/ticket/207 # state column needs new icons ## ticket 206 https://fedorahosted.org/fedoracommunity/ticket/206 # missing release dropdown filter and search filter (for this one should have a 'scratch builds' item in release drop down) ## previous ticket 184 https://fedorahosted.org/fedoracommunity/ticket/184 == Package Details > Maintenance Tools > Changelog == # versions missing for some rows ## see kernel http://127.0.0.1:8080/?package=kernel#package_maintenance/tools/changelog ## ticket 214 https://fedorahosted.org/fedoracommunity/ticket/214 # versions should be strong and authors should be strong ## ticket 213 https://fedorahosted.org/fedoracommunity/ticket/213 # authors should be linked ## ticket 190 https://fedorahosted.org/fedoracommunity/ticket/190 # search filter missing ## previous ticket 184 https://fedorahosted.org/fedoracommunity/ticket/184 == Package Details > Maintenance Tools > Source == # size listing for srpms needs to be styled to match mockup ## ticket 215 https://fedorahosted.org/fedoracommunity/ticket/215 # s/fedora devel/rawhide ## ticket 216 https://fedorahosted.org/fedoracommunity/ticket/216 # cvs version not listed ## ticket 217 https://fedorahosted.org/fedoracommunity/ticket/217 # strong tags for release name, release name links? ## ticket 218 https://fedorahosted.org/fedoracommunity/ticket/218 == Package Details > Maintenance Tools > Updates == # tomboy shows updates for other packages including mono, incollector, lat, gbrainy, etc ## ticket 138 https://fedorahosted.org/fedoracommunity/ticket/139 # release dropdown, status drop down, and search filters missing ## previous ticket 184 https://fedorahosted.org/fedoracommunity/ticket/184 ## note this has a special dropdown filter: status: all | stable | testing & stable | obsolete # status column is missing ## ticket 219 https://fedorahosted.org/fedoracommunity/ticket/219 # updates page takes a very long time to load for kernel ## ticket 220 https://fedorahosted.org/fedoracommunity/ticket/220 # kernel updates page only shows 1 of 10 updates per page. so i can only see, for a 3-page grid, update #1, update #10, and update #20. the rest are missing. ## ticket 221 https://fedorahosted.org/fedoracommunity/ticket/221 # columns do not match mockup. build age missing. status missing. details column (unlabeled in mockup) missing. package column should be version column. ## ticket 222 https://fedorahosted.org/fedoracommunity/ticket/222

1 0

Mockup Comparison Report #1: Overview Pages
by Máirín Duffy 30 Apr '09

30 Apr '09

Hi, I started digging into documenting fine-grained mockup-to-app comparisons. Here's the first chunk, and it includes general observations and comparisons for the overview pages. I'll keep sending these as I finish them; the next section is "my profile". I hope this is a useful format; let me know if not. I'm trying to be careful about checking to make sure a ticket is not already open for an issue before I open a new ticket but if you know one or more of these are redundant please let me know and I'll be happy to close the new redundant one. These are also documented on this wiki page and I'll be adding more to the page as I go along as well: https://fedoraproject.org/wiki/FedoraCommunity/UIReview29Apr2009 ~m ******** OVERVIEW ************* = General = # <title> tag not useful, only says fedora commnunity doesn't say what section ## ticket 149 https://fedorahosted.org/fedoracommunity/ticket/149 # if not logged in, no right sidebars. probably if not logged in, the login right sidebar box should be persistent across pages. ## ticket 150 https://fedorahosted.org/fedoracommunity/ticket/150 # tasks widget (currently named quicklinks, should be named tasks) should be persistent on every page of a logged in user ## ticket 151 https://fedorahosted.org/fedoracommunity/ticket/151 = Overview (logged out) = # latest rawhide builds in mockup, latest builds in app, is this okay? # builds and updates grids show "viewing x of y items" - should we pull this out? it's not in the mockup. right now builds is "Viewing 5 of 100,061 items." not all 100,061 are latest. The 5 shown in the front are latest. ## ticket 152 https://fedorahosted.org/fedoracommunity/ticket/152 # latest builds widget - is not in my timezone. what timezone? is it UTC? should be labeled UTC is so. ## ticket 153 https://fedorahosted.org/fedoracommunity/ticket/153 # latest builds widget - status does not have label, only icon. mockup has labels such as 'success' or 'failure'. ## ticket 154 https://fedorahosted.org/fedoracommunity/ticket/154 # latest builds widget - in mockup, status labels are links. idea for this could be to have a hover menu or link. if success, link to package downloads tab or give hover menu downloads tab for rpms. if failure, hover menu for build error logs or link out to koji page with build error logs ## ticket 155 https://fedorahosted.org/fedoracommunity/ticket/155 = Overview (logged in) = # the alerts widget should have two headers, your packages and all packages. right now it has "this week" and "today" and shows alerts for all packages only. suggest having two h4 headers, "Your Packages" and "All Packages" and two h5 headers for each "This Week" and "Today" ## ticket 156 https://fedorahosted.org/fedoracommunity/ticket/156 # s/quicklinks/tasks ## ticket 157 https://fedorahosted.org/fedoracommunity/ticket/157 # quicklinks is missing the search tasks ## ticket 158 #preview # "my packages" right sidebar widget missing counts in headers ## ticket 159 https://fedorahosted.org/fedoracommunity/ticket/159 # page title missing ## ticket 73 https://fedorahosted.org/fedoracommunity/ticket/73 # grid widgets on page missing display filters "Display: Packages I Own | Packages I Maintain | All Packages") should be for each latest builds, latest testing updates, latest stable updates ## ticket 107 https://fedorahosted.org/fedoracommunity/ticket/107 # status column for builds missing labels ## ticket 154 https://fedorahosted.org/fedoracommunity/ticket/154 # "View more" link is labeled, not just "View more" but "View more updates" "View more builds" etc ## ticket 161 https://fedorahosted.org/fedoracommunity/ticket/161 # by default logging in i see builds for packages i own... not all, in the mockup ## ticket 162 https://fedorahosted.org/fedoracommunity/ticket/162

1 1

update publictest16 (all links now have static versions for opening in a new window)
by John (J5) Palmieri 29 Apr '09

29 Apr '09

In order to make this work you need to tag any link in a mako template (or even static html pages) you wish to be transformed with moksha_url="<dynamic|static>". "static" simply rewrites the href to include the csrf token and any other query string variables that are set. "dynamic" does the static rewrite but also sets up an onClick handler so that the csrf token and query string can be updated when the user clicks and not just when the page load. It will also in the future try to determine if a whole page load is unnecessary and simply switch tabs if that is the case. The only place where you do not add moksha_url is inside of the javascript grid templates since it transforms the template, messing up the final output. The grid will take care of the template links. Come to think of it I still want you to be able to add the markers to the grid template so I am going to look at a way to tell the parser to ignore anything inside javascript templates. For now just assume all links will be transformed to a dynamic url. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

3 3

Licensing
by Tom Callaway 29 Apr '09

29 Apr '09

We've gotten the goahead to use AGPLv3. We need to have a "Get the Source" link to our source landing page that tells people how to get the source (not straight to the git tree) in the footer (it is sufficient for us to meet the AGPLv3 terms). It is also compatible with the Apache license, it has the same compatibilities as GPLv3. ~spot

3 3

PublicText 16 updates (search and people)
by John (J5) Palmieri 29 Apr '09

29 Apr '09

Search is now working. Here are the usecases you want to hit: * Going to the search tab while not logged in - should show basic instructions and no options for selecting people search * Doing an unloggedin search (use 'test') - should show package results * Logging in from the search results using the login button at top right - should bring you back to search with the same search term. you should see a packages and people search results along with check boxes underneath the search bar. * Uncheck packages and hit the search button - should show only the people search result and packages should remain unchecked * Uncheck people and hit the search button - should show both the packages and people search result and both should be checked * Uncheck people again and hit the search button - should show only the packages search result and people should remain unchecked * Hit the search tab to reset the search term - you should see a more detailed description describing the limitations of the people search The people/package maint page now shows that persons builds, updates and alerts (updates are broken right now and will show you all updates). Packages is being worked on. To get here click on a user's name in any builds or updates grid and then select teh top Package Maintenance tab. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

3 4

update publictest 16 (open in new tab/window)
by John (J5) Palmieri 29 Apr '09

29 Apr '09

I've got tabs working as static links when you middle click or use the "open in" context menu item. We basically set the href to be a static link and set a dynamic_href data key to the dynamic address. This makes the dynamic clicks look almost invisible to the user. I still need to do this for other types of links but for now the tabs have this functionality. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

2 1

TurboGears2 status
by Luke Macken 29 Apr '09

29 Apr '09

I created a TG2 page on the wiki to track the progress of the TurboGears2 packaging efforts. https://fedoraproject.org/wiki/TurboGears2 Most of the open bugs just require another pass to fix some minor issues and bring them up to speed with the latest versions. I'll try and chip away at these throughout the week, but feel free to poke at them if you guys are bored. luke

1 0

Navigation Confusion Discussion
by Máirín Duffy 29 Apr '09

29 Apr '09

Hi, In the meeting today Spot brought up a couple of issues with the navigation design that we've known about for a while and maybe should address for milestone 1: - When you're viewing the details of a package, you have three tabs on top - Overview | Builds | Updates. Builds takes you to a list of ALL packages' builds, updates takes you to a list of ALL packages updates, but overview takes you to the overview for the particular package you're looking at. It's internally inconsistent. - When you're viewing the details of a user, the tabs across relate to that single user, not all users. So having tabs that relate to all packages across the top of a single package is inconsistent and thus could bring about confusion. I wrestled with this for much of today and came up with a mockup I'd like to propose we go with to address this problem. Here is the mockup: https://fedoraproject.org/w/uploads/2/22/Fedoracommunity-navrethinking-prop… Here are the changes we'll need to make to do this: * the tabs on the top of the package details pages should be: * Overview * Package Details * Maintenance Tools * s/Package Maintenance/Maintenance Tools - for the right nav bar - I think this wording is more effective at communicating the differences in the link categories. * Add the 'All Packages' navigation with links to all packages, builds, and updates so they are available with only one click. Add this panel to every package details screen. We had considered adding the subnav for 'all packages' under the 'package maintenance' tab in the left nav, but it looks a little awkward (see https://fedoraproject.org/w/uploads/3/39/Fedoracommunity-navrethinking-1.png ) and I am guessing would be more time-consuming to implement. Adding the 'all packages' little panel on the right-hand side I think helps address the concern about being able to access these screens with one click easily from any single package. The general pattern we could adopt from this approach: * Single objects (package details, people profiles) have tabs that relate only to that single object along the top. If that single object has more than one level of navigation, the first level of that object's navigation is represented across the top and sublevels are represented in a navbar panel on the righthand side of the page. * Lists of objects (lists of packages, lists of people) have tabs that relate only to those lists along the top. For example, an area of the UI that is primarily used for showing lists of people would have tabs across the top that were different configurations of lists of people (e.g., "All People", "New People", "Package Maintainers" etc). Tabs that relate to any single object should not be displayed there. * When a single object is part of a larger collection, there should be a panel box in all the pages of its details tabs to link straight out to the relevant collections' navigation. For example, within the details of any pacakge, you should be able to link out to a list of all packages. From the details of any user who is a member of group A, you should be able to link to a list of all users who are members of group A. Does this make sense? What do you think? ~m

3 2

update publictest16 (People and Profile pages)
by John (J5) Palmieri 27 Apr '09

27 Apr '09

Except for some tweaks the people and profile pages are done. I put more links everywhere (missed one I'll get to tomorrow), created the compact info view and cleaned up some of the CSS. Mo the CSS needs to be heavily tweaked for the info stuff as it is not quite like the mockups but about 90% there. The package_maintenance page in people and profiles now have the complete 3rd level nav and look like the mockups. More links link to those pages and switch depending on if you are in people or profile though some links in profile need to be fixed to not link back to people. We also fixed up the live clock to not not display seconds as it was very distracting and having it update once a minute still makes the live clock just as useful without wasting resources both polling and updating the display once a second. I sent a patch upstream which adds the ability to specify the longer timeouts. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

publictest16 update (Yum Package Search)
by John (J5) Palmieri 24 Apr '09

24 Apr '09

Yum package search is now operational and populating through a rawhide database which is updated every hour via a cron script. Yum gets many more results because it also lists subpackages which causes a problem since the packages apps only understand parent package names. To get around this I take the srpm, chop off the version and file extensions and compare that to the package name to see if it is the parent. We only link to the parent but I asked Mo to mock up what it should look like if a user clicks on a subpackage. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

publictest16 update: (Package Maintenance overhaul complete)
by John (J5) Palmieri 23 Apr '09

23 Apr '09

Package Maintenance overhaul is now complete. The new package details and package maintenance tools tabs now get selected when clicking on any of the links in the category navigation. If we want we can even add the All Packages links to that app or just leave it as a separate app. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

2 1

publictest16 update (Updates working, alerts fixed, error logs fixed, tab widget fixes, new mockup for packages 99% done )
by John (J5) Palmieri 22 Apr '09

22 Apr '09

* Updates works again (active releases) - fixed some of my code which checks for status so it works when status is not set (e.g. show me all updates) * Alerts fixed - recent changes which add a username parameter broke alerts when username is not set. Give it a default of None. * error logs fixed - a change to how we register connector methods meant the method was getting the wrong params, fix the method signature to get the right params * tab widget fixes - make sure the tab div id is unique from the whole widget id so we only select li tags inside the tabs div when converting the li's to tabs. Also make sure to use our list of tab li's when clearing the selected tab so that you don't get double selections. Formerly the code was using siblings() to clear the selections but sidebar navigation is split into one ul per category so siblings() would only clear the selection of li's in the same category. * Mo's new mockup is implemented except for the package details and package maintenance tools tabs which are hard to implement because they don't actually change the page like normal tabs do and are two way (i.e. the sidebar nav must tell it's parent nav to switch tabs when a selection in a different category is clicked and vise versa). I'm not sure if it it worth the trouble. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Banners for the Fedora Community Tour
by Máirín Duffy 17 Apr '09

17 Apr '09

Been working on ideas for a tour launched from the front page... http://duffy.fedorapeople.org/temp/misc/fc-banners/banner-pro.png http://duffy.fedorapeople.org/temp/misc/fc-banners/paintain.png ~m

1 0

Code review request: CSRF prevention
by Luke Macken 16 Apr '09

16 Apr '09

Hi everyone, Last night I did a lot of hacking on Moksha's CSRF middleware along with our repoze.who CSRF metadata provider. It seems to be working fine, but I would like a couple more people to review it before we can deem it as safe. Here is the code:: https://fedorahosted.org/moksha/browser/moksha/middleware/csrf.py Test cases:: https://fedorahosted.org/moksha/browser/moksha/tests/functional/test_csrf.py Output of test cases:: CSRFProtectionMiddleware(/) Clearing identity CSRFProtectionMiddleware(/moksha_admin/) Clearing identity CSRFProtectionMiddleware(/login) Clearing identity CSRFMetadataProvider.add_metadata(/login_handler) session cookie= None Invalid session cookie, not setting CSRF token! CSRFMetadataProvider.add_metadata(/post_login) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/post_login) Auth state... rewriting headers response.location = http://localhost/moksha_admin/?_csrf_token=4290e910c55274607ed54bf6a8df5513… CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in GET User supplied CSRF token match environ! CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST User supplied CSRF token match environ! CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= 'cabcb2bf43f60590aafbebbd8ff3430549bfba40manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) Clearing identity Deleting repoze.who.identity from environ Deleting repoze.what.credentials from environ Invalid CSRF token. User supplied (None) doesn't match what's in our environ (4290e910c55274607ed54bf6a8df551387beeabb) Logging the user out CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST Clearing identity CSRFProtectionMiddleware(/) Clearing identity CSRFProtectionMiddleware(/moksha_admin/) Clearing identity CSRFProtectionMiddleware(/login) Clearing identity CSRFMetadataProvider.add_metadata(/login_handler) session cookie= '' Invalid session cookie, not setting CSRF token! CSRFMetadataProvider.add_metadata(/post_login) session cookie= '091657d7699155ff19603ea6a6440e7a49bfba41manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/post_login) Auth state... rewriting headers response.location = http://localhost/moksha_admin/?_csrf_token=28aca41ba0510496c96b2523e9eece52… CSRFMetadataProvider.add_metadata(/moksha_admin/) session cookie= '091657d7699155ff19603ea6a6440e7a49bfba41manager!' Identity updated with CSRF token CSRFProtectionMiddleware(/moksha_admin/) csrf_token_id in POST Clearing identity Deleting repoze.who.identity from environ Deleting repoze.what.credentials from environ Invalid CSRF token. User supplied (4290e910c55274607ed54bf6a8df551387beeabb ) doesn't match what's in our environ (28aca41ba0510496c96b2523e9eece524b4f369e) Logging the user out . ---------------------------------------------------------------------- Ran 1 test in 2.140s OK

2 1

found fix to crazy css problem!!!11
by Máirín Duffy 08 Apr '09

08 Apr '09

I am so excited I just had to send an email!!! I found a solution to the weird CSS issue we've been having with the profile pages user summary rounded box / block. I ran into it again when trying to do the css for the bug dashboard. All is well if the parent div's overflow attribute is set to auto. For whatever reason (and I think this may be a browser bug), the overflow of the parent element is being rendered as if it was set to "visible" (which is not the default value, "auto" should be.) When overflow is set to visible, the way it is supposed to behave is to calculate how tall/wide the content is, and allow it to spill out of its parent block (as opposed to limiting it to the borders of the parent block and adding horiz and/or vert scrollbars, or as opposed to clipping it.) The "auto" property tells the browser 'just figure it out'. For some reason, the browser: (1) thinks that overflow is set to visible for wahtever weird reason (2) thinks the area that needs to spill out of the parent block is way bigger than it actually is. Anyhow, setting overflow: auto seems to fix it for both the profile pages and for the package > bugs page, so expect to see those fixes soon. ~m (ps I am SO EXCITED to find a clean solution to this!)

2 1

Fedora Community Beta Logo
by Máirín Duffy 08 Apr '09

08 Apr '09

Hi, I did three quick mockups of potential beta logos for the Fedora Community app. Any thoughts on which one you'd prefer? Here's the links to the mockups and my take on each: 1. Beta Logo 1: http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta1.png Nobody is going to miss this one. It stands out with a warm color so it's going to be very, very clear the site is in beta. 2. Beta Logo 2: http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta2.png This one is very subtle. The 'beta' might be missed - it fades into the background more and calls less attention to itself. 3. Beta Logo 3 http://duffy.fedorapeople.org/webdesign/My%20Fedora/beta-logos/beta3.png This one is very noticeable like option 1, but it's blingy and shiny while 1 has a more pixel-y style. Any feedback appreciated! Thanks, ~m

4 6

Updates tables - change suggestions (resend)
by Máirín Duffy 03 Apr '09

03 Apr '09

Hi! Today in the status meeting for Fedora Community we talked about the alignment of different version numbers and release names in the updates applications, eg. as shown in this mock: http://fedoraproject.org/w/uploads/1/1a/Myfedora_otherpersonprofile_updates… After looking through the w3c spec on tables, it doesn't appear that there is a good clean way to represent the data as mocked up. So I would like to propose that we add an additional column, "Version", just for the updates tables (it wouldn't affect the other tables) to display the version numbers in a way that aligns them with the other data relevant only to that version number. Doing this cleanly in the HTML means we'll have accessible tables. Here is how the HTML would look with this proposed change: (I'll use ekiga from the mockup as an example): <table> <thead> <tr> <th>Package</th> <th>Version</th> <th>Date Pushed to Stable</th> <th>Release(s)</th> </tr> </thead> <tbody> <tr class="tall-row"> <td class="tall-row-label" rowspan="2">Ekiga</td> <td>2.2.4-7.fc10</td> <td>9 Jan 2009</td> <td>Fedora 10</td> </tr> <tr class="sub-row last-sub-row"> <td>2.2.4-7.fc9</td> <td>9 Jan 2009</td> <td>Fedora 9</td> </tr> </tbody> </table> This is what the HTML will look like given the CSS provided below: http://duffy.fedorapeople.org/temp/misc/Screenshot-1.png What do you think? ~m .header-list table tr.tall-row td, .header-list table tr.sub-row td { border-bottom: none !important; } .header-list table tr.tall-row td.tall-row-label, .header-list table tr.last-sub-row td { border-bottom: 1px solid #c8c8c8 !important; }

2 1

can't make meeting tomorrow
by Máirín Duffy 16 Mar '09

16 Mar '09

Hi, Just wanted to let you know that I can't make the meeting tomorrow... there's a usability test I'm helping out with. ~m

1 0

Re: Please fix your bugs in release instead of rawhide!
by Tom Callaway 11 Mar '09

11 Mar '09

On 03/11/2009 12:04 PM, Adam Williamson wrote: > Well, I don't really see it that way. Here's my workflow - I come across > a link to an Ubuntu bug report (at launchpad.net), so I go and look at > it, and I see the stuff I like - right at the top I can see that it > exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream > code (and I can immediately see the status of the upstream report). This > is the stuff that there's just no good way to do in Bugzilla. Believe > me, I've thought of about sixteen different ways to try and track the > same bug across multiple distribution releases in Bugzilla, and there > isn't any one which handles it as well as Launchpad does. So, the longer term plan is to enable workflows like this in the "Fedora Community" application (used to be called "MyFedora") with moksha. /* Look at our pretty mockups! https://fedoraproject.org/wiki/FedoraCommunity/Mockups */ It won't happen in the first iteration (coming soon!), but it is something that I think we want to target for the second milestone. We'll definitely be looking for feedback on some example workflows that people would like to be able to use in Fedora. ~spot

2 2

myfedora repo now renamed to fedoracommunity
by John (J5) Palmieri 03 Mar '09

03 Mar '09

Trac[1], git[2] and the Wiki[3] have all been moved to a fedoracommunity namespace. The MyFedora name is now formally deprecated. Please report any issues related to this change. Some of the text still talks about MyFedora. We will be removing these references as time permits. To update your git repo either edit .git/config or do a fresh clone and pull your changes from you local myfedora repo (git pull <path to myfedora>) [1] https://fedorahosted.org/fedoracommunity [2] git://git.fedorahosted.org/git/fedoracomunity.git [3] https://fedoraproject.org/wiki/FedoraCommunity -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Monday AM meeting
by Tom Callaway 02 Mar '09

02 Mar '09

Due to snow, I'm going to be calling in to today's meeting. Anyone who would normally be expected to be in the office can feel free to do the same. ~spot

1 0

Meeting this week
by Tom Callaway 25 Feb '09

25 Feb '09

Since I was out of the office on Monday, our weekly status meeting is going to happen at 10 AM Eastern (1500 UTC) tomorrow (Thursday, 02/26). The meetings will be broadcast over Fedora Talk. If you are a Fedora Talk user with a soft/voip phone, you can join the conference via 2001@xxxxxxxxxxxxxxxxx or infrastructure@xxxxxxxxxxxxxxxxxx If you wish to dial in via a normal telephone, choose one of these local numbers: * 919-424-0063 - Raleigh, NC * 312-577-0052 - Chicago, IL * 978-303-8021 - Westford, MA * 650-930-9514 - Sunnyvale, CA * 442030518327 - UK The conference call extension is 2001. ~spot

1 0

Moksha App List
by John (J5) Palmieri 24 Feb '09

24 Feb '09

Here is a exhaustive logical list of application that need to be built. Note that a lot of apps are just cobbling together other apps in the right order and some apps (like the ones in profile and people) are basically the same applications with different filters (for instance the name of the person logged in or the name of the person being looked at). I'm going to go through and distil this list down to a generic list of apps that need to be built. Fedora Community App Breakdown w - denotes a Widget which is synchronously loaded into it's parent during the initial request a - denotes an App which is asynchronously loaded in a seperate AJAX request s - denotes static element inside the parent template ep - denotes extension point • Overview (a) • Fedora Banner (s) - static for now but we could make it a dynamic widget • Builds Table (a) - latest rawhide • Updates Table (a) - latest stable and testing • Feed (w) - Planet Fedora • Login (w) • Alerts (a) • Quick Links (w) • My Packages (w) - compact • My Profile (a) • Info (a) • User Info Box (w) - also need edit user info • Membership Info (a) - miniview • Feed (w) - your latest blog posts • My Packages (w) - canvas and compact • Alerts (a) • Quick Links (w) • Memberships (a) • User Info Box (w) - compact • Membership Info (a) - larger view (approved and unapproved) • Your Packages (w) - compact view • Alerts (a) • Quick Links (w) • Package Maintenance (a) • User Info Box (w) - compact • Packages You Own (a) - full table • My Packages (w) - canvas and compact • Alerts (a) • Quick Links (w) • Package Maintenance (a) • Packages • No package selected • Package Table (a) - list packages • Filter Box (w) - package filters • Package selected • Overview(a) • Description (s) • Latest Rawhide Build (ep) • Owner (s) • Recent Events (a) • Updates Table(a) - Active release overview • Package resource links(s) • Changelog list(a) • Downloads (a) • Downloads table(a) • Maintainers (a) • ACL Table(a) - Users • ACL Table(a) - Groups • Owners(a) • ACL Table(a) - Owners • Watchers(a) • ACL Table(a) - Watchers • Builds • Builds Table(a) • Changelog • Changelog Table(a) • Updates • Updates Table(a) • Bugs • Bugs Table(a) • Builds (a) • Overview (a) • Builds Table (a) - in progress • Builds Table (a) - failed builds • Builds Table (a) - Successful builds • In-Progress, Failed and Successful Builds (a) • Builds Table (a) - whatever type is selected • Quick Links (w) - views for builds • Updates (a) • Overview (a) • Updates Notice Board (a) • Updates Table (a) - Unpushed • Updates Table (a) - Testing • Updates Table (a) - Stable • Unpushed, Testing, Stable (a) • Updates Table Table (a) - whatever type is selected • Quick Links (w) - views for updates • People • Person selected • Info (a) • User Info Box (a) • Membership Info (a) - miniview • Feed (a) - user's blog posts • Users Packages (w) - compact • Alerts (a) - user's alerts • Quick Links (w) • Memberships (a) • User Info Box (a) - compact • Group Memberships (a) • Package Maintenance (a) • Packages Owned (a) • User Info Box (a) - compact • Package Table (a) - filtered on user and owned • Packages Maintained (a) • User Info Box (a) - compact • Package Table (a) - filtered on user and maintained • Builds Overview (a) • User Info Box (a) - compact • Builds Table (a) - in progress filtered on user • Builds Table (a) - failed builds filtered on user • Builds Table (a) - Successful builds filtered on user • In progress Builds (a) • User Info Box (a) - compact • Builds Table (a) - in progress filtered on user • Failed Builds • User Info Box (a) - compact • Builds Table (a) - failed builds filtered on user • Successful Build • User Info Box (a) - compact • Builds Table (a) - Successful builds filtered on user • Updates Overview (a) • User Info Box (a) - compact • Updates Notice Board (a) - filtered on user • Updates Table (a) - Unpushed filtered on user • Updates Table (a) - Testing filtered on user • Updates Table (a) - Stable filtered on user • Unpushed Updates (a) • User Info Box (a) - compact • Updates Table Table (a) - Unpushed filtered on user • Testing Updates (a) • User Info Box (a) - compact • Updates Table Table (a) - Testing filtered on user • Stable (a) • User Info Box (a) - compact • Updates Table Table (a) - Stable filtered on user • No person selected • People Table (a) • Search • Search Bar (w) • Search Results (a) - Packages • Search Results (a) - People -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 1

Added csrf protection and script culling
by John (J5) Palmieri 19 Feb '09

19 Feb '09

So csrf protection is 90% except for the link rewriting and unauthenticated access. The nice this is this will work for all moksha apps, not just TG with one caveat, posts will return the _csrf_token if the app get the post variables directly from wsgi.input. If they get it from the paste cache then the key is stripped so apps don't have to accept **kwds in their controllers or use an application platform specific hook for stripping unknown keywords. In order to get this working for your app you need to add the csrf repoze.who metadata plugin as the LAST plugin and make sure that your authentication plugin sets environ['CSRF_AUTH_SESSION_ID'] to the session id in the IAuthenticatorPlugin. This is because right after Auth we do redirects. CSRF protection trys to protect against unauthorized redirects and links, by setting CSRF_AUTH_SESSION_ID we can tokenize the just added session ID and rewrite the redirect to pass this arg. The plugin is in fedoracommunity/connectors/csrfwhoplugin.py for now but should move to Moksha. There is also a MokshaGlobals widget that injects javascript into the template so javascript can access the csrf token (moksha_csrf_token). In order for this to work templates must include moksha's template/index.mak template or render the resource injector widget which is in the tmpl_context. The TabbedContainer and DashboardContainer fully support URL rewriting for their child apps. How does this all work? When you are logged in repoze.who runs the auth plugin. As mentioned above the auth plugin needs to set environ['CSRF_AUTH_SESSION_ID']. For every request repoze.who runs a list of metadata plugins which fill in the identity information (and in fedora-community's case the repoze.what authorization credentials). When we hit the csrf plugin it will generate the token and set it in identity['_csrf_token']. If CSRF_AUTH_SESSION_ID is set it will overwrite identity['_csrf_token'] with the sha1 of the of the new authenticated session id (remember if this is a new authentication we still have not hit the browser so we have the old session_id). If this is not an authentication request we check the identity csrf token against the _csrf_token parameter sent by the request. If they match, do nothing. If they don't, delete the repoze.what credentials but not the identity. This is why the plugin has to run last. We keep the user logged in (authenticated) but not authorized to do anything so we can offer password-less re-auth. repoze.what predicates will always think the user is anonymous but if an app checks identity directly they will not be protected. In the browser the moksha_csrf_token variable is set as a global and the containers use the moksha.csrf_rewrite_url method to inject the token into the app they are loading. TODO * Write a predicate that checks if the user is authenticated but not authorized so we can notify the user they need to reauth by pressing the login button * transparent url rewriting on link clicks * tg.url monkey patch * determine if a url is external and should not be rewritten. * metadata plugins only run for authenticated users and that is where we strip the token from the params. In order to hack around this we need to add an identity plugin which strips the token and places it in the environ since identity is run every request. This is a hack because we aren't actually identifying a user. Script Culling We now keep a global hash of the scripts that load and strip scripts that have already been loaded. This hashes the whole path so if you load jQuery from two different places it can't distinguish between the two. I may give an option to hash the filename only but this will still break if the file is versioned or compressed with a different name. Have fun. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Menu API
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently added an experimental dynamic menu API to moksha. You can see a demo here: http://65.49.60.166/ (supports right-click menus as well). The API is currently very basic https://fedorahosted.org/moksha/browser/moksha/api/menus/widgets.py And you can see it being used here: https://fedorahosted.org/moksha/browser/moksha/api/menus/default.py I'll be polishing up the API, and writing some documentation for it soon. Cheers, luke

1 0

Moksha Demo Deployment
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I deployed a Moksha demo on my Linode a couple of weeks ago:: http://65.49.60.166/ It's currently deployed using Apache+mod_wsgi, which seems to scale pretty well. In the process of deploying, I added an 'archive_tw_resources' setup.py command, which will extract all widget resources to a local 'toscawidgets' directory, allowing us to have apache serve them up. I committed the mod_wsgi config and application in git. I've also been working on integrating with Nginx + memcached, which is *MUCH FASTER* than the mod_wsgi deployment. I committed the Moksha nginx configuration, along with some helper decorators today. I'll be throwing together some formal documentation for this deployment in the very near future. luke

1 0

ToscaWidget WidgetBrowser integration
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently integrated the ToscaWidgets WidgetBrowser[0] into Moksha, using the new WSGI plugin infrastructure. I'm currently mounting the WidgetBrowser on /docs, which automatically integrates our Sphinx documentation into Moksha itself. This will compile the docs upon startup, and allows us to embed live widget demos into our documentation. You can see an example live widget demo here:: http://65.49.60.166/docs/main/LiveWidget.html Adding a widget demo is as simple as this:: .. widgetbrowser:: moksha.widgets.demos.LiveFeedDemo :tabs: demo, source, template, parameters :size: large Cheers, luke [0]: http://toscawidgets.org/documentation/WidgetBrowser/

1 0

Mounting WSGI applications
by Luke Macken 16 Feb '09

16 Feb '09

Hey all, I recently added support for mounting existing WSGI applications, just as you would mount a TG Controller within Moksha. All you have to do is point to your WSGI app in the ``moksha.wsgiapp`` entry-point like so, and it'll be accessible via the same apps interface:: [moksha.wsgiapp] mywsgiapp = mywsgiapp.wsgiapp:MyWSGIApplication Documentation can be found here: http://65.49.60.166/docs/main/MokshaApplications.html#mounting-an-existing-… luke

1 0

Status Meeting
by Tom Callaway 10 Feb '09

10 Feb '09

Due to me being in route from Europe on Monday, our normal meeting did not happen. I would like to reschedule for tomorrow (Wednesday, Feb 11, 2009) at our usual time (1500 UTC). J5, Mo, Luke, speak now, or I'll assume that you'll be there in person. :) ~spot

3 2

On vacation on friday the 6th, back to work Tuesday the 10th
by John (J5) Palmieri 04 Feb '09

04 Feb '09

Just to let moksha and fedora community people know, I will be taking a four day (2 work day) vacation starting this Friday. I will be back hacking Tuesday morning and will only be reachable by phone in between. If someone needs me get in touch with Luke or Spot and they can relay the message. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Moksha now has placeholders for containers
by John (J5) Palmieri 04 Feb '09

04 Feb '09

What are placeholders? Simply put you can configure an application to load in a container and if it isn't registered yet a placeholder is displayed. Why is this useful? It acts like a live checklist of what needs to be done. Setup your site with all the navigation and applications you are going to use and then write each application and register its entry_point. Every time you finish an application you will nearly instantly see it running on your site. When there are no more placeholders left you know you have completed your site. How do I use them? If you use the containers that reside in moksha.api.widgets.containers you get it for free. Note this only works for the MokshaApp configuration wrappers (and soon the MokshaWidget wrapper). If the container can't find the app you specified in the config it will simply replace it with a placeholder which displays the entry point that could not be found. Implement that entry point, register it and restart your server and the placeholder will disappear leaving you with your running app. I've been laying out the fedoracommunity skeleton so you can check it out there. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Connectors split into seperate middleware and javascript extension point middleware ported to Moksha
by John (J5) Palmieri 04 Feb '09

04 Feb '09

I split the Connectors into a separate middleware so they can be used outside of Moksha. It still relies on Pylons for getting configuration data but I think we should eventually add all config options to parameters in the constructor and let the controlling WSGI app decide how to get that configuration data. Also the server portion of extension points is ported as its own middleware. I haven't moved the client JavaScript yet so right now it will only serve extensions if you request it directly in the format of http://<your_moksha_host>/moksha_extension_point?exttype=<consumable extension point type>. That will send you back javascript as text as you need the client to actually run it. One thing I want to figure out is how to configure extension point directories. Right now only one directory is scanned when you setup the middleware. I would really like it to work like python entry points where multiple egginfos can specify a directory to scan. Right now whoever sets up the middleware chooses the directory. Unfortunately entry points are restricted to python classes, functions and modules. One solution would be to specify that an __init__.py file is added to the directory the extensions are in and to specify the module as an entry point. Then we can just get the directory mapping from the module. The only thing I don't like about this approach is that I would want these files to reside in /usr/share not /usr/lib/python2.5/site-packages. I'm not sure if that is possible. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 1

Meeting Notes for Jan 26, 2009
by Tom Callaway 30 Jan '09

30 Jan '09

Attendees: Luke Macken, John "J5" Palmieri, Mo Duffy, Tom "spot" Callaway Agenda: * Status check on Moksha, where do we stand with our Feb 1 goal target? - Moksha now structured around configurability with various message brokers, does STOMP out of the box - Widget Browser still incomplete, should be done by the end of the week - Module Connectors still incomplete, should be done soon - Koji code done, needs documentation - Bodhi code done, needs documentation - PackageDB code almost done - J5 will send a follow-up email when this code is finished and committed - Extension Points are in progress, should be ported by the end of the week - Containers and tabs need to be documented in the near future - URL Rewriting is incomplete, J5 will open a trac ticket describing what needs to be done * Luke will set up moksha-commits-list and send an email to the moksha list * Mo completed some additional mockups, but still has more to do: - Package Details Mockups - User Profile Mockups - Cleanup front page mockups, both pre-login and post-login, specifically to remove old concepts such as the login box. ~spot

2 2

Message flow
by Luke Macken 26 Jan '09

26 Jan '09

I just checked in support for configurable message flows within Moksha. Out of the box, Moksha does not require an AMQP broker, and will work using the STOMP protocol through Orbited's built-in MorbidQ message broker. I created the high-level idea of a "Topic" within Moksha, which allows applications/consumers/widgets to listen and send messages to them, without having to care about the underlying message protocol or broker. To add support for an AMQP broker, all you have to do is add the following line to your configuration file (tested with Qpid and RabbitMQ): amqp_broker = guest/guest@localhost The MokshaHub will then automatically connect up to your AMQP broker, and will consume all messages from it, forwarding them to the STOMP broker, which will then be consumed by the users web browser. I'll throw together some documentation for this shortly... Cheers, luke

1 0

Re: AMQP status
by John (J5) Palmieri 24 Jan '09

24 Jan '09

I read your second mail already but I wanted to comment on some of the stuff you said in this just so when you sit down with the AMPQ guys we get a clear picture of capabilities (I would like to be in on that discussion BTW, given my experience dealing with message buses). ----- "Luke Macken" <lmacken(a)redhat.com> wrote: <snip/> > > The reason for using AMQP is because of the way the browser consumes > messages from the queues. Right now, widgets can consume messages > from > an AMQP queue over STOMP. However, they have no other capabilities, > such as creating AMQP queues or exchanges, which means that we cannot > properly do AMQP multicasting. I'm not quite sure I understand the multicast bit but in no way do we want to allow a client to create queues from JavaScript. We want them to consume from already existing queues. If they want to request something they go through a connector. AMQP is simply there for push publishing (e.g. signals that an event has happened). > Right now when a client consumes a > message from a given queue -- no one else can consume that message > from > that particular queue. This is a huge roadblock, but there are a > couple > of ways around it... That seems off. Are you sure you are using the correct portion of the spec? Any message bus should be able to distribute a message to anyone who can subscribe to it. Imagine a world where a stock gets updated and only one person can see that message. I think I see the issue looking at some client code. There are Brokers and Queues. Brokers are the bus, anytime they see a message they look to see if any queue is subscribed to that message and put it in that queue. Brokers are inherently multi-casting. More comments bellow. > The ideal solution, from my limited understanding of AMQP, is to have > each client create their own personal (auto-deleting) queue, and bind > it > to a `fanout` exchange. This will allow for multicast AMQP messages. I don't think a fanout is you think it is. It is simply an exchange that ignore routing options when publishing to a queue. e.g. every queue in the exchange gets the message whether or not they requested to listen to it. What we want is for moksha.EventService (or something to that effect) acting as an exchange with one queue per route it is listening to. In effect this would be a queue on the Fedora exchange. The event service would take requests to listen for a topic from live widgets and store their orbitted channel id in a table that associates it with a list of topics (well actually it would be a topics table with a list of orbitted channels). If the topic comes up you send the contents to all the channels which are subscribed. If the channel gets close you take it out of the table. Alternately, you create a queue for each orbitted connection and add routing criteria for listen request from the client. When a message comes into a queue, it gets shipped off to the connection associate with it. The client should only ever care about being able to subscribe to a topic and then have a callback get triggered with the message's payload as a parameter. The client code would look something like this: es = moksha.get_event_service() // perhaps we allow multiple event services with noargs = get default es.subscribe('koji.build.status_changed', status_changed_cb) es.subscribe('koji.build.new_build', new_build_cb) es.subscribe('bodhi.*', bodhi_events_cb) //get all bodhi events def status_changed_cb(json) { alert('koji sent us a status change for build ' + json.build.build_id.toString()); } def new_build_cb(json) { alert('A new build has just started for package ' + json.build.nvr); } def bodhi_events_cb(json){ alert('Bodhi just sent us the ' + json.topic + ' event'); } Our AMQP setup in Fedora would look like: koji, bodhi, fas, pkgdb, etc AMQP producer clients. _____________________________ | Fedora AMQP Exchange | | | | | |Fedora Community | | | |serverside queue | |____| |______________________| | | \|/ ____| |______________________ | | | Moksha AMQP | | | | Client | | | | FC Local Queue | | | | | \|/ | | lookup_conn_for_topic() | |_____|_______________________| / \ / \ |/ \ _________ | |live | | |widget | | |topic | | |consumer | | |#1 | | |_________| | ___\|/___ |live | |widget | |topic | |consumer | |#2 | |_________| -- John (J5) Palmieri Software Engineer Red Hat, Inc.

2 2

Re: AMQP status
by John (J5) Palmieri 23 Jan '09

23 Jan '09

I still don't understand why we are using raw protocols which means I use one set of JS libraries for talking to AMQP and a second set for connector calls. JavaScript should just care about JSON and have a thin layer to request listening to topics which would come in as a json payload through a JS callback. This JS API would be the same no matter what backends we use and could even switch out transports (orbited socket or XMLHTTPRequest) depending on the server setup. AMQP just seems really low level. I would rather JS use the mechanisms it already has for communicating instead of relying on the client to encode and decode various protocols (and potentially triggering latent bugs in those protocols). ----- "Luke Macken" <lmacken(a)redhat.com> wrote: > Hey all, > > I pushed out a bunch of commits last night that added a new > MokshaHub, > along with various AMQPHub implementations. I created the 'AMQPHub' > skeleton class so we would know exactly the functionality we > need/want > from an AMQP module, and thus have the ability to swap them > in-and-out > in the future. I've attempted implementations of this using > python-qpid > (0.10 and 0.8) and amqplib -- the latter being the currently working > version. > > So, right now there is temporary hard requirement on RabbitMQ. I > really > liked how Orbited could utilize it's own built-in message broker out > of > the box, however it only speaks STOMP, not AMQP. So, I threw > together > some basic instructions for setting up RabbitMQ; it should Just Work > out > of the box. > > http://lmacken.fedorapeople.org/moksha/main/RabbitMQ.html > > RabbitMQ has a STOMP adapter, which is why we need it for now. Once > the > AMQP javascript bindings are complete, we'll be able to swap out > RabbitMQ for *any* AMQP broker (most likely Qpid, in our case), and > will > also be able to start using version 0.10 of the AMQP spec (we're > stuck > with 0.8 due to RabbitMQ). > > With regard to the AMQP javascript bindings, I've been talking with > the > Orbited/js.io guys about this for a while now. It seems that > RabbitMQ > already has implemented AMQP in javascript, but it's currently doing > it > over a JSON/HTTP RPC. Swapping out their 'JsonRpcService' for a > 'TCPSocketService' should not be very difficult, and it will allow us > to > hopefully use any AMQP broker on the backend. For now, our widgets > are > stuck speaking STOMP to RabbitMQ. > > > luke > _______________________________________________ > moksha mailing list > moksha(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/moksha -- -- John (J5) Palmieri Software Engineer Red Hat, Inc.

2 2

AMQP status
by Luke Macken 22 Jan '09

22 Jan '09

Hey all, I pushed out a bunch of commits last night that added a new MokshaHub, along with various AMQPHub implementations. I created the 'AMQPHub' skeleton class so we would know exactly the functionality we need/want from an AMQP module, and thus have the ability to swap them in-and-out in the future. I've attempted implementations of this using python-qpid (0.10 and 0.8) and amqplib -- the latter being the currently working version. So, right now there is temporary hard requirement on RabbitMQ. I really liked how Orbited could utilize it's own built-in message broker out of the box, however it only speaks STOMP, not AMQP. So, I threw together some basic instructions for setting up RabbitMQ; it should Just Work out of the box. http://lmacken.fedorapeople.org/moksha/main/RabbitMQ.html RabbitMQ has a STOMP adapter, which is why we need it for now. Once the AMQP javascript bindings are complete, we'll be able to swap out RabbitMQ for *any* AMQP broker (most likely Qpid, in our case), and will also be able to start using version 0.10 of the AMQP spec (we're stuck with 0.8 due to RabbitMQ). With regard to the AMQP javascript bindings, I've been talking with the Orbited/js.io guys about this for a while now. It seems that RabbitMQ already has implemented AMQP in javascript, but it's currently doing it over a JSON/HTTP RPC. Swapping out their 'JsonRpcService' for a 'TCPSocketService' should not be very difficult, and it will allow us to hopefully use any AMQP broker on the backend. For now, our widgets are stuck speaking STOMP to RabbitMQ. luke

1 0

Presentation of Fedora Community available
by John (J5) Palmieri 20 Jan '09

20 Jan '09

Hello all. We just put out a high level presentation of Fedora Community which includes information on where we are going, where we are at, and where we plan to be in the short term. Grab it at http://johnp.fedorapeople.org/fedoracommunity_intro.pdf You can also get my lower level FUDCon presentation at http://johnp.fedorapeople.org/fedoracommunity_fudcon_presentation.pdf -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Monday Meeting
by Tom Callaway 05 Jan '09

05 Jan '09

I've got to work from home on Monday, so if we're having a Monday meeting, we'd have to do it over the telephone. We haven't really announced a public meeting for monday, so my inclination is to push it to next Monday and have a more public announcement of the dial-in and IRC channel, along with the announcement text that J5 worked up. Thoughts? ~spot

2 1

Polymorphic-valued vertical database models
by Luke Macken 23 Dec '08

23 Dec '08

I recently added support for creating polymorphic-valued vertical database models, using SQLAlchemy, to Moksha:: http://lmacken.fedorapeople.org/moksha/main/MokshaModel.html luke

1 0

Should MyFedora/Fedora Community stuff be conducted here also?
by John (J5) Palmieri 19 Dec '08

19 Dec '08

I'm thinking for now it makes sense to have the traffic be here so we cross pollinate on issues and solutions. -- John (J5) Palmieri Software Engineer Red Hat, Inc.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

moksha