Re: request for input re: OpenVPN API

Hi Albert,

Thanks,

I have responded with in-line comments below:

Albert Siersema wrote:
>
> I think you'll find you're better off stating in a short and concise
> manner what it is you're looking for. As lots of open source people
> work on FOSS projects in their spare time or at least have an allotted
> amount of time for a project they won't have to luxury to spend hours
> wading through a paper or to sieve academic language for the bare facts.
>   
Good point!
> When talking to programmers it's better to describe your problem
> in let's say one shortish paragraph, then list the seperate issues/
> challenges. I say list because formatting it like a bulleted list
> works well, especially when discussing issues. It's better to be
> able to quote easily human-parsable statements than to have to
> describe it in lush amounts of text.
> (and thats skipping over the issue that not everyone speaks/reads
>  English as their first language)
>   
Good point again.
Lush amounts of text! Is that a polite way of saying "a bunch of B.S.?"  
:-) 
> Programming/design... when you can't describe your challenges,
> design goals and pitfalls in an orderly concise fashion you
> need to rethink and rephrase.
>   
Yes. I agree.
> You obviously want something with to incorporate VPN functionality
> into a "Grid" of sorts.
> In what sense do you mean "grid" ?
>   
Impossible to answer here given the criteria for communication you so 
eloquently outlined above.
However, if you really want to know, here are some links:

http://www.globus.org/
http://www.ogf.org/

> What makes deploying openvpn in such an environment special ?
>   
> What do you need the API for ?
>   
I will answer both questions at once:

It would need to last indefinitely, and be managed by a remote client, 
using Web Services, with minimal human intervention

If parameters change over time, messages outlining changes must be 
passed to the remote client in specific Web Services format. e.g. I f a 
certificate expires, or is not found because if a change in directory 
structure,  the remote client must be made aware of the cause of the 
failure, so steps can be taken to correct it without having to dig down 
for the information. We may be talking about a large number of 
connections spread over a huge distributed computing environment, so 
human intervention may not be an option.

There may be long periods without traffic. The hold command would likely 
be used here.

The API would be for a local Web Service which would act as an 
intermediary between the VPN server and the remote client. However, I 
think it best if APIs are developed without a specific goal in mind, but 
to serve as an interface to any application which might want to control 
the VPN in the future. So maybe we shouldn't consider the environment 
special at all. That's an argument I make in my paper. But maybe I'm wrong.
> It's all none to clear from your previous messages really.
>   
I think it's easier now that my head is out of my paper, and into 
discussion with people.
> Albert
>   
Thanks again,
Mike


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV