Fwd: OCCI JavaScript libarary
Putting this thread back on the list - see some interesting suggestions from Andrew below: ---------- Forwarded message ---------- From: Andrew de Andrade <andrew@deandrade.com.br> Date: Mon, Oct 26, 2009 at 2:33 PM Subject: Re: [occi-wg] OCCI JavaScript libarary To: Sam Johnston <samj@samj.net> ahh, doh! go ahead. i'm working at home today and I'm using gmail and i forgot to do reply all. On Mon, Oct 26, 2009 at 11:24 AM, Sam Johnston <samj@samj.net> wrote:
Andrew, Great suggestion - do you have a problem with my putting this back on the list? Sam
On Mon, Oct 26, 2009 at 2:13 PM, Andrew de Andrade < andrew@deandrade.com.br> wrote:
true.
There's a bunch of open source management consoles that it may be worth reaching out to in order tog et them on board if they aren't already:
http://www.openqrm.com/ http://virt-manager.et.redhat.com/ http://ovirt.org/
there was a fourth I knew of, but I can't remember the name of it at the moment.
Projects such as Puppet could also be included.
Andrew
On Mon, Oct 26, 2009 at 10:24 AM, Sam Johnston <samj@samj.net> wrote:
On Mon, Oct 26, 2009 at 1:14 PM, Andrew de Andrade <andrew@deandrade.com.br> wrote:
I wouldn't too much about standardizing user experience interfaces. If a standard API interface is created, an open source interface that works with any standard API cloud is sure to come about.
True - it's not even so much about standardising the interface as lowering the barrier to entry. If you can "explore" it as a developer or power user via a web browser and then it behaves the same way for your code (same URLs, relationships, etc. - just different as in native renderings) that's a big win for lowering the barrier to entry. It's also one less thing for providers to build separately, and means that web consoles will have both the freedom to innovate/differentiate while also looking & feeling somewhat similar. Currently there's a mishmash of flash, ajax & html consoles that present a [human] barrier to migration. I agree that this should be a distant second priority, but if we can have it for free then we may as well (and it ought to keep the XML camp happy too). Sam
Further to my last mail I've spent a few hours tonight roughing up the occi.js <http://occi.googlecode.com/hg/code/js/occi.js> Javascript library (test dump page <http://occi.googlecode.com/hg/code/js/index.html>) based on a proof of concept script by Mike Kelly. I'm not sure how rich we want the programmer API to be, or whether it should just be primatives (I'm more leaning towards the latter for simplicity/flexibility) but what's sure is that it should be consistent across whatever client libraries we produce. I'm hoping that Mike and/or other(s) can pick up this module as this really isn't my forté and I already had to buy an O'Reilly eBook to brush up on my rusty Javascript knowledge, anonymous functions, writing libraries, etc. to get this far. Good night^W morning, Sam On Mon, Oct 26, 2009 at 2:35 PM, Sam Johnston <samj@samj.net> wrote:
Putting this thread back on the list - see some interesting suggestions from Andrew below:
---------- Forwarded message ---------- From: Andrew de Andrade <andrew@deandrade.com.br> Date: Mon, Oct 26, 2009 at 2:33 PM Subject: Re: [occi-wg] OCCI JavaScript libarary To: Sam Johnston <samj@samj.net>
ahh, doh!
go ahead. i'm working at home today and I'm using gmail and i forgot to do reply all.
On Mon, Oct 26, 2009 at 11:24 AM, Sam Johnston <samj@samj.net> wrote:
Andrew, Great suggestion - do you have a problem with my putting this back on the list? Sam
On Mon, Oct 26, 2009 at 2:13 PM, Andrew de Andrade < andrew@deandrade.com.br> wrote:
true.
There's a bunch of open source management consoles that it may be worth reaching out to in order tog et them on board if they aren't already:
http://www.openqrm.com/ http://virt-manager.et.redhat.com/ http://ovirt.org/
there was a fourth I knew of, but I can't remember the name of it at the moment.
Projects such as Puppet could also be included.
Andrew
On Mon, Oct 26, 2009 at 10:24 AM, Sam Johnston <samj@samj.net> wrote:
On Mon, Oct 26, 2009 at 1:14 PM, Andrew de Andrade <andrew@deandrade.com.br> wrote:
I wouldn't too much about standardizing user experience interfaces.
If
a standard API interface is created, an open source interface that works with any standard API cloud is sure to come about.
True - it's not even so much about standardising the interface as lowering the barrier to entry. If you can "explore" it as a developer or power user via a web browser and then it behaves the same way for your code (same URLs, relationships, etc. - just different as in native renderings) that's a big win for lowering the barrier to entry. It's also one less thing for providers to build separately, and means that web consoles will have both the freedom to innovate/differentiate while also looking & feeling somewhat similar. Currently there's a mishmash of flash, ajax & html consoles that present a [human] barrier to migration. I agree that this should be a distant second priority, but if we can have it for free then we may as well (and it ought to keep the XML camp happy too). Sam
Quoting [Sam Johnston] (Oct 29 2009):
Further to my last mail I've spent a few hours tonight roughing up the [1]occi.js Javascript library ([2]test dump page) based on a proof of concept script by Mike Kelly. I'm not sure how rich we want the programmer API to be, or whether it should just be primatives (I'm more leaning towards the latter for simplicity/flexibility) but what's sure is that it should be consistent across whatever client libraries we produce.
Sure, client API consistency for multiple implementations is great, but I think that an API specification is out of scope for the group at the moment. IMHO, the group should start to tackle it once the core, and at least some extensions are fully specified. Nice stuff though :-) my $0.02, Andre.
I'm hoping that Mike and/or other(s) can pick up this module as this really isn't my forté and I already had to buy an O'Reilly eBook to brush up on my rusty Javascript knowledge, anonymous functions, writing libraries, etc. to get this far. Good night^W morning, Sam On Mon, Oct 26, 2009 at 2:35 PM, Sam Johnston <[3]samj@samj.net> wrote:
Putting this thread back on the list - see some interesting suggestions from Andrew below:
Andrew, Great suggestion - do you have a problem with my putting this back on
list? Sam
On Mon, Oct 26, 2009 at 2:13 PM, Andrew de Andrade <[7]andrew@deandrade.com.br> wrote:
true.
There's a bunch of open source management consoles that it may be worth reaching out to in order tog et them on board if they aren't already:
[8]http://www.openqrm.com/ [9]http://virt-manager.et.redhat.com/ [10]http://ovirt.org/
there was a fourth I knew of, but I can't remember the name of it at
moment.
Projects such as Puppet could also be included.
Andrew
On Mon, Oct 26, 2009 at 10:24 AM, Sam Johnston <[11]samj@samj.net> wrote:
On Mon, Oct 26, 2009 at 1:14 PM, Andrew de Andrade <[12]andrew@deandrade.com.br> wrote:
I wouldn't too much about standardizing user experience
interfaces. If
a standard API interface is created, an open source interface
works with any standard API cloud is sure to come about.
True - it's not even so much about standardising the interface as lowering the barrier to entry. If you can "explore" it as a developer or
user via a web browser and then it behaves the same way for your code (same URLs, relationships, etc. - just different as in native renderings)
---------- Forwarded message ---------- From: Andrew de Andrade <[4]andrew@deandrade.com.br> Date: Mon, Oct 26, 2009 at 2:33 PM Subject: Re: [occi-wg] OCCI JavaScript libarary To: Sam Johnston <[5]samj@samj.net> ahh, doh! go ahead. i'm working at home today and I'm using gmail and i forgot to do reply all. On Mon, Oct 26, 2009 at 11:24 AM, Sam Johnston <[6]samj@samj.net> wrote: the the that power that's a
big win for lowering the barrier to entry. It's also one less thing for providers to build separately, and means that web consoles will have both the freedom to innovate/differentiate while also looking & feeling somewhat similar. Currently there's a mishmash of flash, ajax & html consoles that present a [human] barrier to migration. I agree that this should be a distant second priority, but if we can have it for free then we may as well (and it ought to keep the XML camp happy too). Sam
References
1. http://occi.googlecode.com/hg/code/js/occi.js 2. http://occi.googlecode.com/hg/code/js/index.html 3. mailto:samj@samj.net 4. mailto:andrew@deandrade.com.br 5. mailto:samj@samj.net 6. mailto:samj@samj.net 7. mailto:andrew@deandrade.com.br 8. http://www.openqrm.com/ 9. http://virt-manager.et.redhat.com/ 10. http://ovirt.org/ 11. mailto:samj@samj.net 12. mailto:andrew@deandrade.com.br
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
On Thu, Oct 29, 2009 at 6:15 AM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Sam Johnston] (Oct 29 2009):
Further to my last mail I've spent a few hours tonight roughing up the [1]occi.js Javascript library ([2]test dump page) based on a proof of concept script by Mike Kelly. I'm not sure how rich we want the programmer API to be, or whether it should just be primatives (I'm more leaning towards the latter for simplicity/flexibility) but what's sure is that it should be consistent across whatever client libraries we produce.
Sure, client API consistency for multiple implementations is great, but I think that an API specification is out of scope for the group at the moment. IMHO, the group should start to tackle it once the core, and at least some extensions are fully specified.
You are, of course, absolutely right. In fact writing client code in general is outside of the scope but it's good for consistency (acting as a poor-man's test suite) and both helps our users and enhances the standard. If we're writing code at all it may as well be consistent, and support by other adaptors like libcloud, deltacloud & simplecloud would also be useful. Mike & I have just got the ball rolling on this one - Mike or someone else interested in Javascript can take it from here. Nice stuff though :-)
Thanks. Sam
Why not just use libvirt? It is already there, controls all VM systems and has all the requisite parts. Chaz Sam Johnston wrote:
On Thu, Oct 29, 2009 at 6:15 AM, Andre Merzky <andre@merzky.net <mailto:andre@merzky.net>> wrote:
Quoting [Sam Johnston] (Oct 29 2009): > > Further to my last mail I've spent a few hours tonight roughing up the > [1]occi.js Javascript library ([2]test dump page) based on a proof of > concept script by Mike Kelly. I'm not sure how rich we want the > programmer API to be, or whether it should just be primatives (I'm more > leaning towards the latter for simplicity/flexibility) but what's sure > is that it should be consistent across whatever client libraries we > produce.
Sure, client API consistency for multiple implementations is great, but I think that an API specification is out of scope for the group at the moment. IMHO, the group should start to tackle it once the core, and at least some extensions are fully specified.
You are, of course, absolutely right. In fact writing client code in general is outside of the scope but it's good for consistency (acting as a poor-man's test suite) and both helps our users and enhances the standard. If we're writing code at all it may as well be consistent, and support by other adaptors like libcloud, deltacloud & simplecloud would also be useful. Mike & I have just got the ball rolling on this one - Mike or someone else interested in Javascript can take it from here.
Nice stuff though :-)
Thanks.
Sam
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Thu, Oct 29, 2009 at 12:10 PM, <eprparadocs@gmail.com> wrote:
Why not just use libvirt? It is already there, controls all VM systems and has all the requisite parts.
That's not a bad idea, but is it not a lower level API dealing with virtualisation directly? For example products like Enomaly use it to control the hypvervisor on the host but then are also candidates for exposing an OCCI API for remote clients. Sam
That makes sense. Thanks. Chaz. Sam Johnston wrote:
On Thu, Oct 29, 2009 at 12:10 PM, <eprparadocs@gmail.com <mailto:eprparadocs@gmail.com>> wrote:
Why not just use libvirt? It is already there, controls all VM systems and has all the requisite parts.
That's not a bad idea, but is it not a lower level API dealing with virtualisation directly? For example products like Enomaly use it to control the hypvervisor on the host but then are also candidates for exposing an OCCI API for remote clients.
Sam
Sure, libvirt makes sense if you were 'not' writing to an occi data model. gary eprparadocs@gmail.com wrote:
That makes sense. Thanks.
Chaz.
Sam Johnston wrote:
On Thu, Oct 29, 2009 at 12:10 PM, <eprparadocs@gmail.com <mailto:eprparadocs@gmail.com>> wrote:
Why not just use libvirt? It is already there, controls all VM systems and has all the requisite parts.
That's not a bad idea, but is it not a lower level API dealing with virtualisation directly? For example products like Enomaly use it to control the hypvervisor on the host but then are also candidates for exposing an OCCI API for remote clients.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Quoting [Sam Johnston] (Oct 29 2009):
Sure, client API consistency for multiple implementations is great, but I think that an API specification is out of scope for the group at the moment. IMHO, the group should start to tackle it once the core, and at least some extensions are fully specified.
You are, of course, absolutely right. In fact writing client code in general is outside of the scope but it's good for consistency (acting as a poor-man's test suite) and both helps our users and enhances the standard.
Absolutely: to have a test suite, or a comprehensive client lib, is great... Best, Andre.
If we're writing code at all it may as well be consistent, and support by other adaptors like libcloud, deltacloud & simplecloud would also be useful. Mike & I have just got the ball rolling on this one - Mike or someone else interested in Javascript can take it from here.
Nice stuff though :-)
Thanks. Sam
References
1. mailto:andre@merzky.net
-- Nothing is ever easy.
participants (4)
-
Andre Merzky -
eprparadocs＠gmail.com -
Gary Mazz -
Sam Johnston