Re: [Launchpad-dev] Adapters API
On Mon, 29 Mar 2010 14:59:12 -0400, Leonard Richardson leonard.richard...@canonical.com wrote: Assuming I understand what you're trying to do, the simplest way to represent this would be to define an annotation like @import_from_adapter() and put @import_from_adapter(IBranchTarget) in IProduct and ISourcePackage, while leaving it out of IPerson and IProductSeries. In IBranchTarget you would have an annotation like @only_used_in_adaptations that would stop it from being exported as a separate entry type. You would publish IBranchTarget.name as branch_target_name (or whatever you wanted) to avoid colliding with a 'name' declared in IProduct or ISourcePackage. The same would hold true for IBranchTargetName's named operations. You can choose whatever name you want, but if that name conflicts with a name found in the original interface, the original interface takes precedence. The end result would be 'product' and 'source_package' looking like they had everything that's @exported in IBranchTarget. Behind the scenes, a product or source package would be adapted to IBranchTarget to retrieve values like 'branch_target_name'. A PATCH that modified (eg.) both name and branch_target_name would make both object modifications within a single database transaction. This just came up again in a different situation, with a couple of additional requirements. What we would like to do is avoid registry importing from so many of the other apps, to avoid the circular dependencies. To do this we are currently looking at having ISomething interfaces in the apps (bugs, code, soyuz etc.) that define an interface relevant to them. This is standard practice for a lot of things, see IBugTarget, IHasBranches etc. The implementations of these are then adapters, which isn't usually the case. class ProductToBugTarget(): adapts(IProduct) implements(IBugTarget) This means that all the bugs-specific code can live in lp.bugs. This means that we want something similar to before, where some IProduct methods should be made available over the webservice by adapting the IProduct and calling the methods on the result. In order to break the circular dependency we need to stop IProduct from deriving from IBugTarget as well. In our experimental branch we define a marker interface in lp.registry for things that can be adapted to bug targets, which helps with registration etc. class IProduct(ICanBeBugTarget): The wrinkle that this has it that it doesn't accomodate the webservice. Currently in order for IBugTarget methods to be available on IProduct they have to be available in the interface that IProduct derives from, currently IBugTarget, which means that bugs code has to be imported in to the registry. Using ICanBeBugTarget means that IBugTarget can't add methods to IProduct right now. Therefore we want a way to annotate that extra methods should be added from the webservice point of view, but crucially, we don't want to import the bugs interface in order to do that. class ICanBeBugTarget(Interface): @import_from_adapter(IBugTarget) requires importing lp.bugs.interfaces.bugtarget.IBugTarget, which gives us the circular dependencies again. Would it be possible for us to instead have something like: class ProductToBugTarget(): @only_used_in_adaptations @add_things_to(IProduct) such that the arrow is drawn the other way, and apps can add things to registry objects without the registry having to import them? I don't see why this can't be done, except that it means that finding out the methods on an object is now a global operation, requiring importing everything and considering the result, rather than just importing the interface and scanning it. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Referer requirement
I work on a Launchpad Greasemonkey Scripts[1] project that includes one script, lp_buttontags.user.js, that is no longer working since Launchpad now requires a referer with post requests. The script is used to tag bug reports which requires loading +edit and then doing a post. My research[2] so far indicates that greasemonkey can not include a referer header when doing a post. I was wondering if there could be something done on the Launchpad side to allow this work again. [1] https://edge.launchpad.net/launchpad-gm-scripts [2] http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/77c94cc17c6b2669?pli=1 Thanks, -- Brian Murray signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Encourage users to provide missing information
On 29 June 2010 03:48, Curtis Hovey curtis.ho...@canonical.com wrote: [1] Downloads is fundamentally broken. Users want in order of precedence: a distro archive, a PPA, a downloadable package, a downloadable release, a branch. The ways users really want to get software are not present. The Download portlet caters to distro packagers and win/mac packages. It sucks to be an Ubuntu user. We cannot decide of the portlet is for stable or development downloads, so the user cannot trust what is listed. Maybe we should move the content of the portlet into the main content where we can elaborate about what it is? We need to replace +downloads with +get-software. +1 To improve this it might be nice to start with some wireframes for what actual projects put on their own /download page and how that would map into Launchpad. You could do worse than just let them provide arbitrary text (with links) for download instructions, so then we can explain which PPA to use, installation instructions, etc. The next thing I would want is an easy way to say and insert here a link to the most recent release on the 2.2 series. People may want to mention more than one series, but they don't necessarily want to mention every active series. Anyhow I suppose there's not much point going into this in detail unless it's scheduled. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Adapters API
On Wed, 30 Jun 2010 07:27:53 +1000, Robert Collins robert.coll...@canonical.com wrote: A few small thoughts if I may. Yay to looser coupling. Sadness at more global state (vs directly expressed dependencies, directly injected connections). I'm not sure what you mean here. Using 'import everything' for your dependency injection seems risky (but I haven't quantified it) to me. Everything isn't a core part of the design, just the easiest thing to express in that one mail. We can vary this part as needed. Lastly, I think that you'd want to check the performance of the global lookup you're adding. Globals are generally evil, and adding more doesn't really feel like a solution to me. I agree that it should be considered, but for the root wadl you have to load everything in anyway, so I don't think there will be a significant impact there. If there are times when we don't have everything loaded and want to list the methods, or find whether a particlar method is valid/where it should be dispatched to then there will be a cost. It would be possible to avoid this my having references to other interfaces to look for webservice declarations on that didn't use symbols, and used strings or something instead. That would avoid the global nature, but at a cost. In addition, having additive behaviour, where features are enabled and disabled as you install different parts of Launchpad, while something that is a long way from actually being possible, would be tougher with that approach. As a parallel, it might be worth seeing it as wanting to provide hook points, similar to bzr, where plugins can extend/modify behaviour, but the core doesn't know anything about the details of the plugins. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] merge proposal mutation vs resubmit
https://bugs.launchpad.net/bugs/596796 https://bugs.edge.launchpad.net/launchpad-code/+bug/596796 and https://bugs.edge.launchpad.net/launchpad-code/+bug/504369 seem to me to show some conflict at the user model level about what kind of changes are allowed in merge proposals after they're created. In bug 596796 Aaron says that he doesn't want to allow changing a prereq after an mp is created, because that changes the meaning of the mp. However, people are already able to change the meaning of an mp after it's created, by pushing new code into it. I think the way that additional changes are shown in the history of an mp are one of the nicer parts: the overall proposal can evolve in response to feedback and you see the ongoing conversation. I'd like to build on the success of that, both in how we show the changes and also perhaps by extending it to other things. If the principle is that mps are entirely immutable after they're created, why don't we disallow changing the code under review? But doing so would be a big step backwards in usability. At the moment it seems that resubmit means wipe the slate clean, so that after a lot of changes we can start a new review. If it has that semantic meaning it would be unfortunate to require people to resubmit just because they made a mistake in creating the proposal. New contributors tend to be confused about whether they should resubmit when they make a change. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
