Hi Sebastian, We just had a chat with supermaz in the IRC regarding the Agent API. We cancelled next Saturday's meeting (20th Dec) because Russell couldn't attend and we got thing sorted out with supermaz. The time and date for the next meeting is not yet set. Summary and full chatlog of our ad-hoc discussion is available here:
http://sourceforge.net/apps/trac/openvpn-als/wiki/agent_api We decided to use REST (+XML) which is simpler and faster than SOAP and does basically the same thing. It is also easy to debug as you can use a web browser. Client support should not be a problem with REST, either. This means the Agent will have a (small) webserver in it responding to requests from (currently localhost) clients applications. These applications can be, for example, GUI's. For example, you could (if you wanted) have a web interface monitoring and controlling local Agent(s). The idea is to extend usage of REST into Agent<->Server interaction later on. Some aspects of this interaction could be replaced pretty easily, e.g. the requests for update of resources (tunnels, applications, webforwards, etc.) sent by the client to the server. I'm not sure if REST supports routing like SOAP (intermediate nodes). If that's proves to be a problem, we can add SOAP support later on. I think we should try to keep the REST clearly separate from the core code, so that it's optional rather than a requirement. With Agent<->Server interaction we need to be more careful with our protocol support. Perhaps SOAP is better for that, I don't know. Could you elaborate what the "securenode" functionality did/does? Does usage of REST prevent that? Anyways, you're most welcome to the Agent API team if you like. The best way to participate is to hang around in the #adito IRC on freende.net or send lots of mails to this list :). I assume you're in the CET timezone? Samuli > Hi all, > > sorry for my poor english, > > I've read the chatlog and think the agent go in the right direction ... the > server ... i don't know > > first I think a pure swing gui would be perfect. why? sometimes i've only > 56kbit/s and the 4MB swt shit (no support for new plattforms, e.g. vista-64 > or solaris on x86 - okay now it is suported, but take 3 or 4 month and need > changes at "the code") takes 1-2 minutes for download an then the agent > can't connect to the server (timeout). do it, please. > > soap communication for the agent. It would be nice. The communication > between server<->agent should use soap, too. I think soap is her the right, > ?rest is more for crud-applications?. and agent as deamon. why not? I think > the next step extent it to be a "securenode from sslexplorer enterprise" or > use it on a gateway/router, which remote port enabled tunnels, in a > "branch"-office. > > yes your are on the right way too life up openvpn-als to the next level ... > sry can't not help you :( - I hope it change in a few month. > > sebastian > > On Thu, 17 Dec 2009 09:24:45 +0200, "[email protected]" > <[email protected]> wrote: > >> Hi Mathias, >> >> I took a look at SOAP yesterday and got a good idea how it functions. It >> could definitely do the job but _is_ pretty complex and has >> functionality we should not need (e.g. routing). However, it seems >> pretty versatile and extending it from the Agent API to Agent<->Server >> communication should be easy. For example, the Agent occasionally polls >> the server for a list of active resources (e.g. tunnels). This kind of >> responses should be easy to wrap into a SOAP message. One potential >> problem with SOAP is that each endpoint has to be either a client (doing >> queries) or a server (answering queries). Also, would need to add >> authentication information into SOAP messages if we extend it's use to >> Agent<->Server communication. >> >> I have no personal preference over SOAP or REST. Mathias, do you think >> could we easily extend REST into Agent<->Server communication, too? >> >> Samuli >> >> >> >> >> >> >> >> >>> Hi all, >>> >>> >>> >>> I'm more or less sure that we should use REST for the client API. >>> >>> >>> >>> It is based on HTTP and URIs which should be able to use by any client >>> >>> software and programming language. The only thing that we must decide is >>> >>> what the payload should look like. We could transfer any kind of data >>> >>> using >>> >>> REST, e.g. XML, JSON, plaintext, bytecode, etc. >>> >>> >>> >>> I think the two most usefull formats would be XML or JSON with a >>> >>> preference (by me) of XML. >>> >>> >>> >>> Then we would have the power of XML messages but a little less overload >>> of >>> >>> the communication compared to SOAP. >>> >>> >>> >>> But that's only one of the many ways to go... >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Matthias Jansen >>> >>> >>> >>> >>> >>> On Wed, 16 Dec 2009 09:51:18 +0200, "[email protected]" >>> >>> <[email protected]> wrote: >>> >>> >>> >>>> Hi all, >>>> >>>> >>> >>> >>> >>> >>>> The next Agent API meeting is held on the #adito IRC channel at >>>> >>>> >>> >>> >>>> freenode.net next Saturday at 2:30PM CET. More information about Agent >>>> >>>> >>> >>> >>>> API is available here: >>>> >>>> >>> >>> >>> >>> >>>> http://sourceforge.net/apps/trac/openvpn-als/wiki/agent_api >>>> >>>> >>> >>> >>> >>> >>> >>> >>>> Samuli >>>> >>>> >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------------ > >>> >>> >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> >>>> >>> >>> >>>> Take advantage of Verizon's best-in-class app development support >>>> >>>> >>> >>> >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> >>>> >>> >>> >>>> easy >>>> >>>> >>> >>> >>>> Join now and get one step closer to millions of Verizon customers >>>> >>>> >>> >>> >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> >>>> >>> >>> >>>> _______________________________________________ >>>> >>>> >>> >>> >>>> Openvpn-als-devel mailing list >>>> >>>> >>> >>> >>>> [email protected] >>>> >>>> >>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/openvpn-als-devel >>>> >>>> >>> >>> >>> >> >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Openvpn-als-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openvpn-als-devel >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Openvpn-als-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openvpn-als-devel > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Openvpn-als-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-als-devel
