[Launchpad-dev] The rate of API changes in stable?
Hi, I came to know that Launchpad edge is going to be removed, so my question is that how often will the stable install have it's API changed? Actually right now Launchpad only has a python library, and I was working on creating a CLI wrapper over it. I started long back in April, but has to shelve the project due to some personal reasons. I am back now. Bit of history --- Right now I have a project called wadlsharp which generated C# code from the WADL file. This C# code is then compiled and distributed as launchpad-sharp (I have got the permission from Mark Shuttleworth to use the trademark). Whenever the API gets updated the WADL changes which changes the code. This introduces a problem that the update to the API results to new C# code and new launchpad-sharp library. Updating this would surely be a pain. Leonard suggested that using reflection and generating the final CLI assembly would be good. The problem is that this workflow is tough. Actually very tough. The WADL still has many limitations and some of the bugs are still lying around assigned in Launchpad Foundation. So I decided to go with generating manually, validating personally, compiling them and distributing. This can introduce errors if not handled properly. I just wanted to know what is the new release period for stable install of launchpad? Even if it is 2-3 weeks, how much are the chances of something breaking. I don't think that important things like Bug, Person, Team should drastically change to an extent of breaking. Atleast important methods like *bug.newMessage* or *branch.createMergeProposal* -- I don't think the parameters supplied should change Ditto for return values -- Manish ___ 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] Some Error when Getting Launchpad
Hi, I was trying to get Launchpad source using the way mentioned here https://dev.launchpad.net/Getting On the way it tried branching a repo, which failed The error was bzr: ERROR: Not a branch: bzr+ssh:// bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/. When I tried opening this in the browser as http://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/; all I get is === Unauthorized You are logged in as foo === Probably that repo is private or does not exist. In this case most of the people outside of Canonical can't access it. I am confused why this error is coming. Or there is a minor problem in the rocketfuel-setup ? -- Manish Sinha http://manishtech.wordpress.com ~manishsinha ___ 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] Some Error when Getting Launchpad
This error is expected for us non-Canonical people. It is, however, not fatal, and everything should continue to work fine. Max. Yes. I continued ignoring that error. I was able to set up launchpad and got it running. I just wanted to know if it was a obselete thing in the setup script or really for non-canonical people. BTW Thank you. -- Manish ___ 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] Launchpad's service WADL clarification
Hi Gary,
So this mens I need to have a look at wadllib and lazr.restt projects.
Let me summerize what I understoo.
wadllib is a parser for wadl files. It takes in a wadl string and
creates the corrospoding tree to corrospond with the schema so that
you can acess any method like application.resource_type.method
The parsed object from wadllib is passed to lazr.rest which traverses
the wadl tree reoresentation and creates the client side proxy.
Hope I got it correct.
--
Manish Sinha
On 5/13/10, Gary Poster gary.pos...@canonical.com wrote:
Manish and I spoke on IRC today. We made progress on the two topics he
raised there. I'll summarize here for clarity, history, and community (IOW,
please correct me!).
The first issue Manish described in this email, so I'll respond below.
On Apr 25, 2010, at 4:18 AM, Manish Sinha wrote:
Hi,
I am working on a WADL--C# converter and taking Launchpad WADL file as
the example. This project is mainly targeted at generating client proxy
code for Launchpad.
I ran into a few issues:
in the request section of WADL, it can contain param[] and
representation_type[] both together
I can understand that param[] can be used for generating a method which
has all the parameters given in param[]
For representation_type[] I understood that the method is overloaded and
each there are as many overloaded methods as the number of
representation_type
My doubt comes that, when both param[] and representation_type[] are
present in a single request.
Let's take we have m param and n representation_type
In this case, does all the methods look like?
foo(param1, param2,.,paramm, representation_type1)
foo(param1, param2,.,paramm, representation_type2)
...
..
foo(param1, param2,.,paramm, representation_typen)
Or in most situations param[] and representation_type[] wont occur
together? Can I safely assume this?
I know many people on this list don't deal with development and not many
use WADL since they are comfortable with launchpadlib.
It would be kind if some launchpad hacker answers this question. If anyone
is familiar with WADL, your suggestions are appreciated. If the hacker who
wrote Launchpad WADL can answer this, it would be a cherry on the ice.
I believe this question is about porting the behavior of lazr.restfulclient,
rather than wadllib.
I like the way that lazr.restfulclient and wadllib handle this, and, as I
said on IRC, I'd suggest considering porting these libraries, if possible,
rather than making your own architecture.
In that context, the libraries handle the situation you raise in this way.
wadllib simply parses the wadl and gives a nice way of getting the data from
it, like a specialized XML DOM object. You can get the parameters of a
given method for a given representation type. For instance, if you have a
wadllib object representation of a method named WADL_RESOURCE, you can ask
it questions like WADL_RESOURCE.parameter_names('application/json') to get a
list of the parameter names for that call and resource type.
lazr.restfulclient then explicitly exposes all of the JSON methods. The
methods then only have parameters in them, and *never* (AFAICT) let the
caller specify the representation type (since JSON is always used).
The second question you raised was that the getByUrls method of branches in
our WADL doesn't specify a return type. I asked you to file a bug, which
you did: https://bugs.launchpad.net/bugs/579516 .
Gary
--
Sent from my mobile device
___
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] Launchpad's service WADL clarification
On 5/11/2010 5:57 PM, Gary Poster wrote: Hi Manish. Thank you for your work. Leonard won't be available till next week, and he is the expert. The only other person I know who might answer is also unavailable right now. Maybe there is another person who can speak up now, but in case you don't get a reply right now, I wanted you to know the situation. Hi Gary, This confusion still persists. Till date I have recieved replies which are mere speculations of what it should be. No clear cut answer. Here is the conversation between Me and James on this issue. James: https://lists.launchpad.net/launchpad-dev/msg03267.html Me: https://lists.launchpad.net/launchpad-dev/msg03268.html James: https://lists.launchpad.net/launchpad-dev/msg03269.html Me: https://lists.launchpad.net/launchpad-dev/msg03270.html James: https://lists.launchpad.net/launchpad-dev/msg03271.html Me: https://lists.launchpad.net/launchpad-dev/msg03272.html I am just hoping to hear from Leonard or anyone who made this WADL file. I had a small conversation with Leonard on IRC related to the design of the library[1] , but this WADL issue is still unsolved [1] http://dl.dropbox.com/u/1237964/IRC-Logs/leonardr-OnMail.txt -- Manish Sinha ___ 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] Want feedback on LaunchpadSharp
Apart from all in the previous mail, I would like to ask a few more questions. All these examples are hypotheical just for sake of discussion and clarification 1) If version 1.0 of LP has a entity *bug* and a method names *checkBugIsValid* , then if you change the name of method to *checkBugValidity* in v2.0 , then the client will generate the proxy for it. Now the problem comes with applications which have always been using method *checkBugIsValid* will break. Isn't it? How does launchpadlib actually deal with it? This means that applications have to be made for a specific version of launchpad API version? If my application is named foo, then it means I need to have backend names libfoo-lp1.0 and libfoo-lp2.0 If only one application has to be maintained, then how will the application know that to check that the bug is valid, it needs to call which method name. Atleast this much hardcoding has to be there. The application needs to know which actual method to call when someone clicks on the button Check if the Bug is Valid 2) I was thinking of making the correct version in the following way: One component which takes in the WADL string and creates the library (dll) which can be loaded at runtime. Applications when started first check which version of LP is available. As per the latest stable release, it downloads the WADL file, sends this to the component mentioned above which created the library and this library is sent back the application which loads it at runtime. Loading modules/assemblies at runtime is supported by CLI. Mono also supports it [ http://www.go-mono.com/docs/index.aspx?link=M%3aSystem.Reflection.Assembly.LoadFile%28System.String%29 ] Once the assembly is loaded (like loading modules in Python), then rest everything continues as required. Is what I said above correct and feasible? Please let me know. By that time I am off to learn Reflection. -- Mainish Sinha http://launchpad.net/~manishsinha ___ 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] Want feedback on LaunchpadSharp
Hi everyone, For the last few days I have been working on creating Mono/.NET client wrappers on Launchpad API. I love Python but my day job involves a lot of C# coding, so I thought it would be good to have multiple client wrapper for this API so that the potential of Launchpad can be exploited to the maximum. I know many people can be skeptical of Mono, but as a programmer I wanted even Mono developers of Windows developers on C#.NET to start using Launchpad or even better host their Open Source Projects on this platform. Let me explain Aurthur about the project: =wadlsharp= Launchpad provides a WADL file describing the API for the web-service. I wrote a WADL-C# converter called wadlsharp[1] . Actually with minor modifications it can even create VB code but that is not the current target. wadlsharp is just a library and I am yet to write it's documentation. I created wadlsharp just to create the C# client code so that customizing the generated C# code can as easy as possible. I have released v0.1 of wadlsharp. Get the code from bzr[2] or download the tarball[3] =LpSharp= Using the generated C# code, I have completed implementation of OAuth specific to LP. For all the HTTP methods supported in Launchpad - GET, POST, PUT, PATCH and DELETE, I have implemented GET as of now. The project is still under development, but I wanted to send a mail to inform everyone that such an effort is underway and they can send their comments using which I can prevent serious design mistakes or even accept patches for this project. The name of this project is Launchpad#[4] I have already take the permission for using the word Launchpad which is a trademark of Canonical. I would humbly request everyone to look at the source code and send their valuable feedback so that I can make it better. Both the projects are licensed under MIT / X11 / Expat license [1] https://launchpad.net/wadlsharp [2] https://code.launchpad.net/~manishsinha/wadlsharp/trunk [3] http://launchpad.net/wadlsharp/trunk/release-v0.1/+download/LpNet.WadlSharp.Common.tar [4] https://launchpad.net/lpsharp/ CCing all the Canonical devs with whom I have talked earlier when I was about to start working on LpSharp (Launchpad#) -- Manish Sinha http://launchpad.net/~manishsinha ___ 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] Launchpad's service WADL clarification
Hi, I am working on a WADL--C# converter and taking Launchpad WADL file as the example. This project is mainly targeted at generating client proxy code for Launchpad. I ran into a few issues: in the request section of WADL, it can contain param[] and representation_type[] both together I can understand that param[] can be used for generating a method which has all the parameters given in param[] For representation_type[] I understood that the method is overloaded and each there are as many overloaded methods as the number of representation_type My doubt comes that, when both param[] and representation_type[] are present in a single request. Let's take we have m param and n representation_type In this case, does all the methods look like? foo(param1, param2,.,paramm, representation_type1) foo(param1, param2,.,paramm, representation_type2) ... .. foo(param1, param2,.,paramm, representation_typen) Or in most situations param[] and representation_type[] wont occur together? Can I safely assume this? I know many people on this list don't deal with development and not many use WADL since they are comfortable with launchpadlib. It would be kind if some launchpad hacker answers this question. If anyone is familiar with WADL, your suggestions are appreciated. If the hacker who wrote Launchpad WADL can answer this, it would be a cherry on the ice. P.S. I had initially sent this mail to launchpad-users instead. Sending it to the correct list now, -- Manish ___ 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] Launchpad's service WADL clarification
On 4/25/2010 4:35 PM, James Westby wrote: Do you have an example of an element that has both param and representation_type? Nope. That's why am asking whether such a situation can exist? If this is a theoretical question that I think you can assume this. I think the fuller implementation would be that the parameters defined directly and those in the representation types would never overlap, so that param foo representation_type A param bar representation_type B param baz This means that we have two overloads for this methods . This corrosponds to methodname(foo, bar) methodname(foo,baz) What am considering is that the child of request can contain either param[] or representation_type[] , not both together, which makes param foo1 param foo2 param foo3 AND representation_type foo1 representation_type foo2 representation_type foo3 LEGAL WHEREAS param foo1 representation_type foo2 param foo3 representation_type foo4 representation_type foo5 IS ILLEGAL. More info is is here http://www.w3.org/Submission/wadl/#x3-180002.9 which says that as per the schema param[] and representation_type[] exist together and what I marked ILLEGAL is actually legal as per the schema. Confusion escalated. :( would be legal, but param foo representation_type A param foo would not be. The specification doesn't seem to be explicit about this though. P.S: Sorry for use of ALLCAPS for a few words. It was just for emphasis. ___ 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] Launchpad's service WADL clarification
On 4/25/2010 6:25 PM, James Westby wrote: No, it means that the method takes any/all of the union of the parameters defined directly with param or as part of a representation. Meaning in this case the method signature would be methodname(foo, bar, baz) From WADL submission 1. Zero or more |representation| elements - see section 2.11 http://www.w3.org/Submission/wadl/#x3-210002.11. Note that use of |representation| elements is confined to HTTP methods that accept an entity body in the request (e.g., PUT or POST). Sibling |representation| elements represent logically equivalent alternatives, e.g., a particular resource might support multiple XML grammars for a particular request. ___ 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
