I can see that there are some proposals to RESTful descriptions, not standard. Quick google search tells me that some people have been there with proposals: http://microformats.org/wiki/rest/description
Also I can see that there is yet another religious discussion on whether or not descriptions are a good idea for restful services, but I haven't seen a argument for why descriptions are a bad idea. Why is it bad for an application to know in advance which attributes it can expect for an object. And if the reason is that the server itself doesn't know them, then it should be solved as a key-value set of userdata on the object. Anyway Ladon does not accept unknown attributes, so we can easilly support some kind of description language for REST. / Jakob 2012/10/23 Mykhailo Stadnyk <[email protected]> > Sure, I think I'm an adequate :) I also just would like to find the best > solution. I told - it's just a proposal, and I made some thoughts on it, > just share them with you. Finally, our goal the same - to provide the best > solution to the end-user. BTW, I just don't know how to provide service > description - it's something out of the existing standards. That's why I > was asking in the past - what to do with that? > > Mike > > 2012/10/23 Jakob Simon-Gaarde <[email protected]> > >> Hi Mike >> >> I hope you understand that I'm not rejecting your proposal at all :-) >> just throwing balls in the air and alternative suggestions so we can reach >> the best solution. Tonight I am gonna review your branch in more detail and >> give you some feedback. >> >> Earlier you mentioned that all you really need to describe the restful >> service is a list of objects. I don't entirely agree with this unless that >> list also contains object info ie. attribute names and types. >> >> >> / Jakob >> >> 2012/10/23 Mykhailo Stadnyk <[email protected]> >> >>> Initially I was supposed to implement in some kind of way, but just >>> using the class-level decorator. But! It is too strict and not as flexible >>> as could be. >>> I told already taht I imagine that exposing RESTful methods might be a >>> bit more flexible. Let's imagine that I already have some SOAP service >>> which is easily could map to REST by exposing the methods (assuming that >>> SOAP service is "almost RESTful", but all I need is to expose to HTTP GET >>> not a single method but several). You can look at, for example, JAX-WS - >>> the REST implementation is something like in my proposal. You put TOO >>> strict constraints for the REST service, mine is more flexible. I propose >>> to developer to decide what does he want to do with his service (he might >>> want to have 2 POST, 5 GET, 1 PUT and no DELETE HTTP methods exposed for >>> concrete service object). This mapping could be easily done by matching the >>> arguments passed through an HTTP, so the rule is a following: >>> 1. If you have several methods exposed to the same type of HTTP >>> request, which method to call is determined by matching the bypassed HTTP >>> params and the service method arguments >>> 2. REST is not RPC, so you can not tell which method to call by name, >>> but we can call different methods relying on their signatures >>> >>> 1,2 - the same but with different words. >>> >>> Regards, >>> Mike >>> >>> 2012/10/23 Jakob Simon-Gaarde <[email protected]> >>> >>>> Let's try to define the end-user result, and then discuss the >>>> implementation afterwards. >>>> >>>> In the following I have defined a very simple type as a case we can >>>> collaborate through. >>>> >>>> Maybe we have an object called Client that needs to be RESTful. I think >>>> the nicest thing to do would be to SubClass LadonType (ie. >>>> RESTfulLadonType) which has some virtual methods: >>>> >>>> class Client(RESTfulLadonType): >>>> >>>> uid = PORTABLE_STRING >>>> name = PORTABLE_STRING >>>> account = PORTABLE_STRING >>>> credit = bool >>>> >>>> def get(self,id): >>>> pass >>>> >>>> def put(self,id): >>>> pass >>>> >>>> def delete(self,id): >>>> pass >>>> >>>> Ladon sees right away that some og the objects used in the Service >>>> class are RESTful and adds restful to the list of protocols. >>>> Your turn! >>>> >>>> / Jakob >>>> >>>> >>>> >>>> 2012/10/23 Jakob Simon-Gaarde <[email protected]> >>>> >>>>> I knew this already :-) And that's not nessesarilly a bad thing, >>>>> depending on what you are developing. I just think we need to think >>>>> through >>>>> how to implement it in Ladon. Since you have enjoyed using Ladon until >>>>> now, >>>>> you probably already know that I am a hugh fan of end-user simplicity. >>>>> >>>>> And since REST is strictly object-oriented, I really think we should >>>>> be looking at decorating the LadonType instead of methods. I haven't >>>>> thought it all the way through yet, but I'm almost sure that would be the >>>>> place to do it. >>>>> >>>>> >>>>> / Jakob >>>>> >>>>> >>>>> 2012/10/23 Mykhailo Stadnyk <[email protected]> >>>>> >>>>>> Exacly! REST is a constraint to objects by design! You've caught it. >>>>>> But it's good principal for data-oriented services with no overhead by >>>>>> any >>>>>> top-level protocol. It's a principal of building RESTful services. And >>>>>> will >>>>>> be good if Ladon will support it >>>>>> >>>>>> 2012/10/23 Jakob Simon-Gaarde <[email protected]> >>>>>> >>>>>>> But, I think I know what you mean. It's the fact that it utilizes >>>>>>> all HTTP methods that makes you say that REST is in the HTTP protocol. I >>>>>>> just don't nessesarily find that this is very revolutionary. It's more >>>>>>> of a >>>>>>> constraint, cause you are limited to objects by design. >>>>>>> >>>>>>> / Jakob >>>>>>> >>>>>>> >>>>>>> 2012/10/23 Mykhailo Stadnyk <[email protected]> >>>>>>> >>>>>>>> For REST HTTP is not underlying level but the protocol itself. In >>>>>>>> terms of REST design of service is known, so all you need is just to >>>>>>>> describe a list of objects. And then for each object there is 4 >>>>>>>> operations >>>>>>>> you are able to perform Create (HTTP PUT), Read (HTTP GET), Update >>>>>>>> (HTTP >>>>>>>> POST) and Delete (HTTP DELETE). That's why in terms of REST you do not >>>>>>>> need >>>>>>>> the description. You have only URLs each representing the object you >>>>>>>> can do >>>>>>>> direct HTTP requests and you have no overhead of having some top-level >>>>>>>> protocol, etc. That's why I said that REST is HTTP, because there is >>>>>>>> nothing on top of HTTP in REST. And there is nothing to describe, only >>>>>>>> the >>>>>>>> object URLs. >>>>>>>> >>>>>>>> It means that RESTful service architecture is not as flexible as >>>>>>>> SOAP, so if you, as developer decided to create RESTful service it >>>>>>>> means >>>>>>>> that you already chosen the service architecture. It also means that >>>>>>>> not >>>>>>>> every SOAP service can be RESTful, but RESTful service could be >>>>>>>> delivered >>>>>>>> with SOAP. >>>>>>>> So you, as developer MUST decide first if you are building a >>>>>>>> RESTful service, if so - go ahead, make it and Ladon give you benefit >>>>>>>> to >>>>>>>> deliver your RESTful service throug varius different supported >>>>>>>> protocols. >>>>>>>> >>>>>>>> Again. You CAN deliver RESTful service throug >>>>>>>> SOAP/XML-RPC/JSON-WSP/etc. But you CAN NOT deliver abstract >>>>>>>> SOAP/XML-RPC/JSON-WSP service through REST if it wasn't designed as >>>>>>>> RESTful >>>>>>>> >>>>>>>> In my implementation I've tried to make everything with maximum >>>>>>>> flexibility, so each RESTFul service could have more than 4 CRUD >>>>>>>> methods, >>>>>>>> for each HTTP request method you can have as many service methods as >>>>>>>> you >>>>>>>> need if the service methods have different signatures (arguments) >>>>>>>> >>>>>>>> like >>>>>>>> >>>>>>>> class Service: >>>>>>>> @restfulize(method="GET") >>>>>>>> def get_one_record( r_id): >>>>>>>> pass >>>>>>>> @restfulize(method="GET") >>>>>>>> def get_last_record( r_time): >>>>>>>> pass >>>>>>>> @restfulize(method="GET") >>>>>>>> def get_all_records(): >>>>>>>> pass >>>>>>>> @restfulize(method="GET") >>>>>>>> def get_filtered_records( filters): >>>>>>>> pass >>>>>>>> >>>>>>>> As you see in this example 4 service methods are bind to HTTP GET >>>>>>>> method. Depending of parameters bypassed through HTTP I try to >>>>>>>> determine >>>>>>>> which method to call, but from terms of protocol you always do >>>>>>>> >>>>>>>> GET >>>>>>>> /Service/rest?filters['name']=*bla&filters['another_key']=somevalue >>>>>>>> HTTP/1.1 >>>>>>>> Host: yourservice.com >>>>>>>> ... >>>>>>>> >>>>>>>> The same for other HTTP methods. You can have 2 different methods >>>>>>>> for POST, for example for User service example you may have split User >>>>>>>> data >>>>>>>> update and user password update, etc.. >>>>>>>> >>>>>>>> Or maybe your service may not provide some methods. Like you create >>>>>>>> the public read-only service, so you don't provide PUT/POST/DELETE >>>>>>>> >>>>>>>> P.S. REST does not provide the way do bypass which service method >>>>>>>> to call by name. REST is not RPC. You have only the Resource, it's URL >>>>>>>> and >>>>>>>> 4 operations. It is REST. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> 2012/10/23 Jakob Simon-Gaarde <[email protected]> >>>>>>>> >>>>>>>>> Everything in Ladon is HTTP :-) >>>>>>>>> >>>>>>>>> But HTTP is just the underlying protocol, and under that is a >>>>>>>>> transport protocol etc. >>>>>>>>> >>>>>>>>> When I am talking about protocol in Ladon I mean service protocols >>>>>>>>> like soap, json-wsp and soon json-rpc which are also protocols. I >>>>>>>>> would put >>>>>>>>> REST at this level aswell. >>>>>>>>> >>>>>>>>> I haven't really used REST before, but from what I can see it is >>>>>>>>> nothing more than another service protocol which utilizes the HTTP >>>>>>>>> standard >>>>>>>>> a bit more, like using PUT,POST,GET,DELETE methods. Also it looks like >>>>>>>>> there is not so much constraint on how parameters are passed so they >>>>>>>>> can be >>>>>>>>> JSON or XML or query-string. >>>>>>>>> >>>>>>>>> I don't like that there is no service description format for REST >>>>>>>>> services. That is kind of a key feature in Ladon, that all supported >>>>>>>>> protocols should be able to describe themselves. >>>>>>>>> >>>>>>>>> >>>>>>>>> / Jakob >>>>>>>>> >>>>>>>>> 2012/10/22 Mykhailo Stadnyk <[email protected]> >>>>>>>>> >>>>>>>>>> What do you mean? >>>>>>>>>> >>>>>>>>>> Actually REST is HTTP in terms of protocol, so what do I need to >>>>>>>>>> implement? Maybe you can explain me more detailed your thought. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> 2012/10/22 Jakob Simon-Gaarde <[email protected]> >>>>>>>>>> >>>>>>>>>>> My first question about your RESTful implementation is, why are >>>>>>>>>>> you not implementing it as a protocol? >>>>>>>>>>> >>>>>>>>>>> / Jakob >>>>>>>>>>> >>>>>>>>>>> 2012/10/22 Jakob Simon-Gaarde <[email protected]> >>>>>>>>>>> >>>>>>>>>>>> Just a remark about the package name tracepyd. That might be an >>>>>>>>>>>> unfortunate package name, cause on that odd platform called Windows >>>>>>>>>>>> pyd-files are binary python modules. Just a remark :-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2012/10/22 Jakob Simon-Gaarde <[email protected]> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Mike. >>>>>>>>>>>>> >>>>>>>>>>>>> Let's talk about tracepyd first, does it solve this bug: >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.launchpad.net/ladon/+bug/877727 >>>>>>>>>>>>> >>>>>>>>>>>>> rpclib has a terribly ugly solution for this, as you can see >>>>>>>>>>>>> in the bug, and we want to be better than rpclib :-) >>>>>>>>>>>>> >>>>>>>>>>>>> / Jakob >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2012/10/22 Jakob Simon-Gaarde <[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Mike >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking into this now, you will have my reply today :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> / Jakob >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2012/10/22 Mykhailo Stadnyk <[email protected]> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently it's an experimental feature which is not ready to >>>>>>>>>>>>>>> be integrated. I didn't test it at all (keep working on it). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So here is my personal road-map for this feature: >>>>>>>>>>>>>>> 1. Resolve problem with decorators dependencies (something >>>>>>>>>>>>>>> I described in previous message) >>>>>>>>>>>>>>> 2. Write tests and test the functionality >>>>>>>>>>>>>>> 3. I've not checked how does it deal with requests >>>>>>>>>>>>>>> containing multipart boundaries and binary data >>>>>>>>>>>>>>> 4. Not sure what to do with service description (currently >>>>>>>>>>>>>>> I've just removed, but have an idea we can use it to describe >>>>>>>>>>>>>>> service any >>>>>>>>>>>>>>> way, even as long as REST does not specify this) >>>>>>>>>>>>>>> 5. Write documentation/examples >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But I'm stuck on issue #1. I want to know: >>>>>>>>>>>>>>> * do you agree to add dependency in Ladon to tracepyd >>>>>>>>>>>>>>> module or not? >>>>>>>>>>>>>>> * If not - do you agree to include tracepyd's >>>>>>>>>>>>>>> implementation into Ladon (not as dependency, but to place it >>>>>>>>>>>>>>> somewhere in >>>>>>>>>>>>>>> tools)? >>>>>>>>>>>>>>> * If not - do you agree to modify @ladonize decorator >>>>>>>>>>>>>>> functionality to add extra-params for REST (for me its ugly). >>>>>>>>>>>>>>> * If not - which ideas do you have then? :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd like to suggest to add dependency to tracepyd. Currently >>>>>>>>>>>>>>> I have a version locally which works fine, so I can publish >>>>>>>>>>>>>>> this solution >>>>>>>>>>>>>>> to my branch to let you see. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you in advance for your time and advice, >>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/10/22 Jakob Simon-Gaarde <[email protected]> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interesting :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll look at it later - we must make sure that it doesn't >>>>>>>>>>>>>>>> break anything. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2012/10/22 Mykhailo Stadnyk <[email protected]> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Jacob. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As I told I'm trying to implement RESTful services support >>>>>>>>>>>>>>>>> by Ladon. The basic functionality is implemented - you can >>>>>>>>>>>>>>>>> check my branch: >>>>>>>>>>>>>>>>> lp:~mikhus/ladon/rest<https://code.launchpad.net/~mikhus/ladon/rest> >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> see how does it work. Here is an example of RESTful service >>>>>>>>>>>>>>>>> you may run to >>>>>>>>>>>>>>>>> see: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> from ladon.ladonizer import ladonize, restfulize >>>>>>>>>>>>>>>>> from ladon.compat import PORTABLE_STRING >>>>>>>>>>>>>>>>> from ladon.types.ladontype import LadonType >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> class User(LadonType): >>>>>>>>>>>>>>>>> name = PORTABLE_STRING >>>>>>>>>>>>>>>>> email = PORTABLE_STRING >>>>>>>>>>>>>>>>> passwd = PORTABLE_STRING >>>>>>>>>>>>>>>>> def __init__(): >>>>>>>>>>>>>>>>> self.name = "" >>>>>>>>>>>>>>>>> self.email = "" >>>>>>>>>>>>>>>>> self.passwd = "" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> class UserService( object) : >>>>>>>>>>>>>>>>> @restfulize(method="PUT") >>>>>>>>>>>>>>>>> @ladonize(str, str, str, rtype=User) >>>>>>>>>>>>>>>>> def newUser( self, u_name, u_email, u_passwd) : >>>>>>>>>>>>>>>>> user = User() # where User is LadonType object >>>>>>>>>>>>>>>>> user.name = u_name >>>>>>>>>>>>>>>>> user.email = u_email >>>>>>>>>>>>>>>>> user.passwd = u_passwd >>>>>>>>>>>>>>>>> return user >>>>>>>>>>>>>>>>> @restfulize(method="GET") >>>>>>>>>>>>>>>>> @ladonize(int, rtype=[User]) >>>>>>>>>>>>>>>>> def getUser(self, u_id) : >>>>>>>>>>>>>>>>> return User() >>>>>>>>>>>>>>>>> @restfulize(method="GET") >>>>>>>>>>>>>>>>> @ladonize(int, rtype=[User]) >>>>>>>>>>>>>>>>> def getUsers(self) : >>>>>>>>>>>>>>>>> return [User(), User(), User()] >>>>>>>>>>>>>>>>> @restfulize(method="POST") >>>>>>>>>>>>>>>>> @ladonize(int, str, str, str, rtype=User) >>>>>>>>>>>>>>>>> def updUser( self, u_id, u_name, u_email, u_passwd): >>>>>>>>>>>>>>>>> user = User() >>>>>>>>>>>>>>>>> user.name = u_name >>>>>>>>>>>>>>>>> user.email = u_email >>>>>>>>>>>>>>>>> user.passwd = u_passwd >>>>>>>>>>>>>>>>> return user >>>>>>>>>>>>>>>>> @restfulize(method="DELETE") >>>>>>>>>>>>>>>>> @ladonize(int, rtype=bool) >>>>>>>>>>>>>>>>> def delUser( self, u_id) : >>>>>>>>>>>>>>>>> return True >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> By the way, there is at least one issue I don't know how >>>>>>>>>>>>>>>>> to solve better, so I want your advice. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As you see I've implemented specific decorator to mark >>>>>>>>>>>>>>>>> service methods as RESTful. It's @restfulize decorator. The >>>>>>>>>>>>>>>>> problem that it >>>>>>>>>>>>>>>>> is implemented now as: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> def restfulize( *dargs, **dkwargs): >>>>>>>>>>>>>>>>> def decorator(fn): >>>>>>>>>>>>>>>>> * minfo = fn._ladon_method_info* >>>>>>>>>>>>>>>>> if 'method' in dkwargs: >>>>>>>>>>>>>>>>> if not minfo.restfulize( **dkwargs): >>>>>>>>>>>>>>>>> raise RestfulMethodConfigMismatch( fn.func_name) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> return fn # returns ladonized method >>>>>>>>>>>>>>>>> return decorator >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The problem is highlighted with bold. Will be good to make >>>>>>>>>>>>>>>>> this decorator independent of what @ladonize defined in it's >>>>>>>>>>>>>>>>> private props. >>>>>>>>>>>>>>>>> But, as far as "fn" here is a reference to ladon's "injector" >>>>>>>>>>>>>>>>> function I >>>>>>>>>>>>>>>>> have no way to determine correctly which real method in which >>>>>>>>>>>>>>>>> class is >>>>>>>>>>>>>>>>> decorated. It means that in such case I have no way to extract >>>>>>>>>>>>>>>>> LadonMethodInfo associated to "fn" in other way but >>>>>>>>>>>>>>>>> implemented for the >>>>>>>>>>>>>>>>> moment. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The real problem is when I want to override @ladonize >>>>>>>>>>>>>>>>> decorator. In this case @resftulize becomes nonoperational >>>>>>>>>>>>>>>>> because I loose >>>>>>>>>>>>>>>>> reference to "_ladon_method_info" and means that I should >>>>>>>>>>>>>>>>> take care to >>>>>>>>>>>>>>>>> bypass all the existing private properties in 3-d party >>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>> implementation, which is not good at all. So I want to have >>>>>>>>>>>>>>>>> @restfulize and >>>>>>>>>>>>>>>>> @ladonize implemented without hard dependency between them. >>>>>>>>>>>>>>>>> Via global_service_collection() it's possible to do but >>>>>>>>>>>>>>>>> you need to determine real method function in some way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I see the following ways to fix it: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. Via decorator registry (Here we solved such kind of >>>>>>>>>>>>>>>>> problem by creating DecoratorRegistry (I've published it as >>>>>>>>>>>>>>>>> http://pypi.python.org/pypi/tracepyd)) >>>>>>>>>>>>>>>>> 2. By adding REST functionality to @ladonize decorator >>>>>>>>>>>>>>>>> itself, to have something like: >>>>>>>>>>>>>>>>> @ladonize(PORTABLE_STRING, rtype=[PORTABLE_STRING], >>>>>>>>>>>>>>>>> *rest={ >>>>>>>>>>>>>>>>> "method" : "GET", "produces": "XML" }*) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Maybe you can point me to some other ideas you know how to >>>>>>>>>>>>>>>>> resolve such kind of problem. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>>>>>>>>> Jakob Simon-Gaarde >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>>>>>>> Jakob Simon-Gaarde >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>>>>>> Jakob Simon-Gaarde >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>>>>> Jakob Simon-Gaarde >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>>>> Jakob Simon-Gaarde >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Med venlig hilsen / Best regards >>>>>>>>> Jakob Simon-Gaarde >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Med venlig hilsen / Best regards >>>>>>> Jakob Simon-Gaarde >>>>>>> >>>>>>> -- >>>>>>> Mailing list: https://launchpad.net/~ladon-dev-team >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~ladon-dev-team >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Med venlig hilsen / Best regards >>>>> Jakob Simon-Gaarde >>>>> >>>> >>>> >>>> >>>> -- >>>> Med venlig hilsen / Best regards >>>> Jakob Simon-Gaarde >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~ladon-dev-team >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~ladon-dev-team >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >> >> -- >> Med venlig hilsen / Best regards >> Jakob Simon-Gaarde >> >> -- >> Mailing list: https://launchpad.net/~ladon-dev-team >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~ladon-dev-team >> More help : https://help.launchpad.net/ListHelp >> >> > -- Med venlig hilsen / Best regards Jakob Simon-Gaarde
-- Mailing list: https://launchpad.net/~ladon-dev-team Post to : [email protected] Unsubscribe : https://launchpad.net/~ladon-dev-team More help : https://help.launchpad.net/ListHelp
