xmpp unified cloud interface (UCI) extension

[sal]

Hi,

having an XMPP Estension protocol for this aim would be a great
things!
I am investigating, just as a matter of theoretical exercise (or
research if you prefer) how, and where xmpp could help and also as
Paulo suggested in his post (http://www.cloudviews.org/2009/01/cloud-
it-or-not-to-cloud-it-interoperability/) which other protocols we can
reuse to support it (e.g. OAuth, Uddi o xrds).

However I haven't seen any proposal or discussion in this group about
it. Is anyone working on this?

I haven't seen any follow up to the Reuven Cohen post claiming that he
is working on this.
Reuven are you still working on this issue?

/sal

[Reuven Cohen]

Sal, I am trying to work on this, but my time is limited. I could
certainly use some help. I don't want to be the only person pushing
this forward, UCI needs to be a broader industry initiative. Let's
arrange a time to talk about this further.

Reuven

[sal]

sure,
I am interested even if at present just from a research point of view

so at moment there isn't any idea yet on how to use xmpp,
on which extension build our extension (i.e. which extension can be
reused, which need to be extended etc. etc). Isn't it?

... I was hopping you have started to write down some draft or
proposal

/Sal

[Peter Saint-Andre]

I'd be happy to help with this in a few weeks (I'm booked until then).

/psa

[Andy Edmonds]

We've been experimenting with XMPP for the provisioning of virtual
machines (and architecting for the inclusion of physical machine
provisioning) and would also appreciate the opportunity to take part
in the discussions. Our work is the output of our on going efforts on
SLA@SOI, an EU FP7 research project [1]. If some one is needed to host
a confcall we can facilitate that.

Regards,

Andy

[1] http://sla-at-soi.eu

IT Research - IT Innovation Centre - Intel Ireland Ltd.
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

[Reuven Cohen]

Andy, nice to meet you. I'd like to arrange a group conference call with several of the interested collaborators for next week.

We're also working with Intel (Open Cirrus), I can give you more details in private msg.

reuven

--
--

Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
www.enomaly.com :: 416 848 6036 x 1
skype: ruv.net // aol: ruv6

blog > www.elasticvapor.com
-
Open Source Cloud Computing > www.enomaly.com

[Egon Willighagen]

Dear Sal,

On Fri, Jan 23, 2009 at 12:06 PM, sal <salvator...@ieee.org> wrote:
> having an XMPP Estension protocol for this aim would be a great
> things!
> I am investigating, just as a matter of theoretical exercise (or
> research if you prefer) how, and where xmpp could help and also as
> Paulo suggested in his post (http://www.cloudviews.org/2009/01/cloud-
> it-or-not-to-cloud-it-interoperability/) which other protocols we can
> reuse to support it (e.g. OAuth, Uddi o xrds).

Please also checkout the IO-DATA proposal for machine-to-machine communication.

http://xmpp.org/extensions/xep-0244.html

We have a working Java implementation (xws4j.sf.net, written by
Johannes) for the server and client side, with nice features.

We have demo service running here in Uppsala (on ws1.farmbio.uu.se,
use DISCO for service discovery),
and two clients available for end users (Bioclipse, Taverna). I
blogged about the latter here:

http://chem-bla-ics.blogspot.com/search?q=xmpp

It's in high flux, and I am looking forward to comments and possibly
collaboration.

Kind regards,

Egon

--
----
http://chem-bla-ics.blogspot.com/

[Reuven Cohen]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing Interoperability Forum (CCIF)" group.
To post to this group, send email to cloud...@googlegroups.com
To unsubscribe from this group, send email to
cloudforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cloudforum?hl=en

-

Egon, this looks very interesting, thank you for sharing the link.

reuven

[sal]

Hi Andy,

I have had a quickly look to the project site and the slides,
it looks extremely interesting!

About the XMPP experimenting you have performed
do you have any results , questions, doubts, or impression to share?

cheers
Sal

[sal]

Hi Egon,

interesting, I think this is the kind of food for thoughts that we as
group need
thanks for sharing.

Unfortunately we are an earlier stage and we don't have still anything
structured to share

About the collaboration, thanks! I think too it would be interesting:
I'll answer you privately.

cheers
Sal

On 24 Gen, 09:08, Egon Willighagen <egon.willigha...@gmail.com> wrote:
> Dear Sal,
>

[Andy Edmonds]

Hi Sal,
I'm currently collecting and summarising our experiences with XMPP (which are far from over) and will post them up to the group.

Andy
andy.edmonds.be

[Andy Edmonds]

Hey Rueven - likewise - good to meet you. Do let me know know more on
both mentioned topics (confcall, opencirrus).

Andy

On Jan 24, 2:52 am, Reuven Cohen <r...@enomaly.com> wrote:
> Andy, nice to meet you. I'd like to arrange a group conference call with
> several of the interested collaborators for next week.
>
> We're also working with Intel (Open Cirrus), I can give you more details in
> private msg.
>
> reuven
>

> Founder & Chief Technologist, Enomaly Inc.www.enomaly.com:: 416 848 6036 x 1

[Jayson Vantuyl]

Hi sal,

My company's been doing some good work on building a solid protocol on
top of XMPP for roughly this purpose.

Strictly speaking, it's a little more general, but we've been
extracting it from our provisioning software, so it's exactly tailored
for being an XMPP "Cloud glue" sort of thing. We hope to submit it as
an XEP once the protocol has completely stabilized (probably about
0.5).

It's open-sourced under the LGPL and you can read about our progress
at http://vertebra.engineyard.com . We're at version 0.3, about to
release 0.4, with about as much development as that implies.

Thanks,

[Reuven Cohen]

Jayson, the Vertebra project looks very promising, but without industry buy in, consensus or even agreement on what cloud computing is, it would seem rather early to define your platform as potential protocol. Whether you're open source or closed source is secondary at this point. It's seems that engineyard had an itch and went ahead and attempted to scratch it and I commend you for taking the initiative, we need more companies like yours.

Actually, code aside, I think the biggest issue with Vertebra would be the choice in using the LGPL license, which isn't exactly compatible with very many other open source licenses other then GPL variants. For a standard protocol to emerge, i think we need to fully embrace an open API, one that can be freely used regardless of platform, license or otherwise. I'd look to an apache or BSD style license, something closer to the public domain.

That said, keep up the great work and I look forward to your continuing involvement on the interoperability front.

Reuven

[Eric Anderson]

Let me just say that I agree with this comment about the LGPL. Using
any form of GPL makes it a non-option for a lot groups, and can
severely inhibit rapid growth and acceptance. I think more people
should ask the question "what am I protecting?" before slapping a
license on something.

Eric

[Jack Moffitt]

>> Actually, code aside, I think the biggest issue with Vertebra would
>> be the choice in using the LGPL license, which isn't exactly
>> compatible with very many other open source licenses other then GPL
>> variants. For a standard protocol to emerge, i think we need to
>> fully embrace an open API, one that can be freely used regardless of
>> platform, license or otherwise. I'd look to an apache or BSD style
>> license, something closer to the public domain.
>

> Let me just say that I agree with this comment about the LGPL. Using
> any form of GPL makes it a non-option for a lot groups, and can
> severely inhibit rapid growth and acceptance. I think more people
> should ask the question "what am I protecting?" before slapping a
> license on something.

The LGPL/GPL is a non-issue for a protocol; it only affects the
implementation. As EngineYard has said they plan to pursue
standardization within the XSF, you can probably rest assured that the
protocol itself will be covered by the same license the other XEPs are
under.

It seems to me that licensing the implementation under the LGPL is
extremely smart, as those companies which cannot abide by its terms
will have a strong incentive to purchase some commercial license if
EngineYard plans to go that route. We do a similar thing with
Strophe's licensing (an XMPP client library).

If the XEP is to become a draft standard within the XSF there will
need to be more than one implementation regardless. If more people
feel strongly about the LGPL as you two do, then I imagine a second
implementation will emerge under a different license.

jack.

[Reuven Cohen]

 We also use a similar license within our Enomaly ECP platform, (AGPL) which gives us a sustainable revenue model. Previously we used the LGPL but found it too limiting and focused on application libraries. We ended up abandoning the LGPL in our V2.x release.

Reuven

[Andy Edmonds]

If licensing issues still remain, I for one will be highly interested in implementing such an XEP within the SLA@SOI project, whos software outputs will be issued under the Apache 2.0 license.

Andy
andy.edmonds.be

[Reuven Cohen]

On Mon, Jan 26, 2009 at 12:12 PM, Andy Edmonds <andy.e...@gmail.com> wrote:

If licensing issues still remain, I for one will be highly interested in implementing such an XEP within the SLA@SOI project, whos software outputs will be issued under the Apache 2.0 license.

Andy
andy.edmonds.be

I second that, and can commit to inclusion of any potential XEP draft unified cloud API / Spec as part of our Enomaly ECP platform.

I think we need to take a closer to look at the Vertebra XMPP implementation and outline any missing parts.

reuven

[Jayson Vantuyl]

We carefully weighed the options for license. LGPL does not prevent
anyone who wants to use this software from using it. It does not
infect anything that links to the library, only contributions to the
library itself. Vertebra is designed so that it's value is divided
into interoperability (the LGPL part) and functionality (the part that
the customer contributes to most). That is based on the assumption
that they won't need to contribute to the core libraries. In that
respect, we intend to keep the core technology open source. LGPL !=
GPL and serious people know that. Whoever attempts to unify the
cloud, they won't get there with BSD. Prepare for the Unix wars all
over again, and expect a thousand incompatible implementations.

Industry consensus did us a great job of showing exactly how large,
entrenched providers can jockey for position without respect to actual
innovation. I see all those functional, interoperable deployments of
X.500, cross-implementation LDAP replication, and CIFS. Oh wait,
they're not there. Bottom line, no cloud provider has an interest in
making themselves accessible. Industry buy-in does not equal
deployment. In fact, it's usually the other way around. I don't
expect to see any major cloud vendor deploying an "open standard" that
they don't own. From that angle, LGPL makes at least as much sense as
Linux did, and the GPL hasn't seemed to stop anybody there.

If someone is so concerned with the license, we own all of the IP will
be glad to give them a more permissive license for a fee, so that
option is also available.

In general, industry buy-in is going to come from interoperability, no
more, no less. With BSD, you're depending on goodwill for that.
You're guaranteeing that no responsible organization will be able to
command the funds or control to deliver interoperability. You're
setting yourself up to be like the any number of BSD guys, Sun,
Microsoft, or Apple will be living large off of your code (SSH, TCP-IP
Stack, and FreeBSD respectively) and we won't be a step closer to
interoperability. Don't get me wrong, I love Amazon. They're an
investor in Engine Yard (although that in no way implies endorsement
of our product). I've had lunch with a number of the other big guys
as well. They may be shopping around for protocols, but unification
doesn't give them anything much.

From that perspective, relying on a standard that makes the Clouds
uniform is sort of a red herring. We can develop the perfect standard
and have only goodwill to get it implemented. Unifying Clouds is good
business for the customer, but not so much the provider. When they
eventually figure it out, it'll be a tech war just like any other. In
the end, you've got to offer something more compelling, and that's why
Vertebra has the scope that it does. If there's one thing I've
learned from Linus Torvalds, is that good software gets deployed
regardless of the license. Just as all of those enterprises about
their Linux deployments and you'll see how little that matters in the
face of functionality.

[Jayson Vantuyl]

Interesting. We actually shied away from the AGPL precisely because
it's more infective than the LGPL.

As the LGPL goes, it's the least viral license short of BSD. In the
end, it's about keeping the library open without infecting anything
else. If you want interoperability and you think open source will get
you there, I don't see how BSD equates to much more than giving your
code to people who will put you out of business. And if you're not in
the cloud to be in business, well, why not? :)

[Jayson Vantuyl]

Any standard will certainly not be LGPL. LGPL only applies to code.
The protocol is designed to be open, documented, and as accessible as
can be.

[Peter Saint-Andre]

Jayson Vantuyl wrote:
> Any standard will certainly not be LGPL. LGPL only applies to code.
> The protocol is designed to be open, documented, and as accessible as
> can be.

At least at the XMPP Standards Foundation, our protocol licensing is
very open (essentially MIT license):

http://xmpp.org/extensions/ipr-policy.shtml

/psa

[Reuven Cohen]

@psa Looks like a lot of the various XEP proposals user their own licenses ranging from GPL to MIT.

@jayson, if the motivation for interoperability isn't API level unification, then what are we working towards and why?

[Peter Saint-Andre]

Reuven Cohen wrote:
>
>
> On Mon, Jan 26, 2009 at 2:06 PM, Peter Saint-Andre <stp...@stpeter.im
> <mailto:stp...@stpeter.im>> wrote:
>
>
> Jayson Vantuyl wrote:
> > Any standard will certainly not be LGPL. LGPL only applies to code.
> > The protocol is designed to be open, documented, and as accessible as
> > can be.
>
> At least at the XMPP Standards Foundation, our protocol licensing is
> very open (essentially MIT license):
>
> http://xmpp.org/extensions/ipr-policy.shtml
>
>

> @psa Looks like a lot of the various XEP proposals user their own
> licenses ranging from GPL to MIT.

Huh? They all use the same license.

/psa

[Reuven Cohen]

 Actually the XEP licensing isn't very clear. Where did you see the MIT license mentioned?

r/c

[Peter Saint-Andre]

Reuven Cohen wrote:

> Actually the XEP licensing isn't very clear. Where did you see the MIT
> license mentioned?

I didn't say it was MIT license, I said it was *essentially* MIT. We
made a few very slight modifications to the MIT license to refer to
specifications instead of software. The legal notices that all XEPs are
required to carry are described here:

http://xmpp.org/extensions/ipr-policy.shtml#legal

And all XEPs do include that text.

I don't know what is so confusing.

/psa

[Reuven Cohen]

I seemed to have missed this part.

3.1 Ownership
By submitting an XMPP Extension for consideration by the XSF, the
author of the Extension shall assign any ownership rights or other
Claims asserted over the Extension to the XSF. This does not apply to
Claims regarding any Implementations or Deployments of the Extension,
but rather to the Extension itself as represented in a protocol or
data format. Any documentation of the Extension (in the form of a XEP
specification) shall be copyrighted by the XSF. Once an author assigns
ownership to the XSF, the XSF shall in turn make the Extension
available to all entities so that they may create, use, sell,
distribute, or dispose of Implementations or Deployments of XMPP and
all XMPP Extensions in perpetuity and without payment or hindrance.

Thanks for clearing things up. :)

[Jayson Vantuyl]

Developing the Cloud as a platform. Most people are very image-
centric. We are building a Cloud-scale / Cloud-reliable application
framework that provides a real base for managing apps in the Cloud,
not just instances. We think that API unification doesn't get us much
without having something reliable enough to deliver it. XMPP gets us
close, but there's a little more that we think Vertebra tackles.

On Jan 26, 11:11 am, Reuven Cohen <r...@enomaly.com> wrote:

[Jayson Vantuyl]

Licensing a protocol is a strange idea for us. It's like licensing a
document format. We just don't see it as the same thing. Licensing
code is something much more tangible than licensing the wire
protocol. It's akin to trying to license "transferring data with
ASCII". While it could be done, we don't really see the sense in it.
Perhaps we aren't aggressive enough with our definition of "IP".

[Peter Saint-Andre]

Jayson Vantuyl wrote:
> Licensing a protocol is a strange idea for us. It's like licensing a
> document format. We just don't see it as the same thing. Licensing
> code is something much more tangible than licensing the wire
> protocol. It's akin to trying to license "transferring data with
> ASCII". While it could be done, we don't really see the sense in it.
> Perhaps we aren't aggressive enough with our definition of "IP".

To be precise, the licensing applies to the specifications. IMHO a
protocol is as free as the air.

/psa

[tmor...@gmail.com]

On Jan 26, 11:11 am, Reuven Cohen <r...@enomaly.com> wrote:

API for what? :-)

Vertebra is more of a distributed application framework. We believe it
would
be ideal to build an instance provisioning API atop Vertebra, which
would
allow each cloud provider to implement actors for their
infrastructure.

--
-- Tom Mornini

[Aneel]

Andy, is your work related to the Reservoir project?
http://www.reservoir-fp7.eu/

-Aneel.

On Jan 23, 5:23 pm, Andy Edmonds <andy.edmo...@gmail.com> wrote:
> We've been experimenting with XMPP for the provisioning of virtual
> machines (and architecting for the inclusion of physical machine
> provisioning) and would also appreciate the opportunity to take part
> in the discussions. Our work is the output of our on going efforts on
> SLA@SOI, an EU FP7 research project [1]. If some one is needed to host
> a confcall we can facilitate that.
>
> Regards,
>
> Andy
>
> [1]http://sla-at-soi.eu
>
> IT Research - IT Innovation Centre - Intel Ireland Ltd.
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> On Jan 23, 4:32 pm, Peter Saint-Andre <stpe...@stpeter.im> wrote:
>

> > sal wrote:
> > > sure,
> > >  I am interested even if at present just from a research point of view
>
> > > so at moment there isn't any idea yet on how to use xmpp,
> > > on which extension build our extension (i.e. which extension can be
> > > reused, which need to be extended etc. etc). Isn't it?
>
> > > ... I was hopping you have started to write down some draft or
> > > proposal
>

[Andy Edmonds]

Hi Aneel - at the moment the work, although sharing some common
aspects and goals, is unrelated. SLA@SOI [1] and RESERVOIR [2] are two
FP7 IP's (integrated projects). However, we would like to work closely
with Reservoir and ideally integrate at some future stage.

Andy
andy.edmonds.be

[1] http://sla-at-soi.eu
[2] http://reservoir-fp7.eu

On Jan 27, 1:16 pm, Aneel <anee...@gmail.com> wrote:
> Andy, is your work related to the Reservoir project?http://www.reservoir-fp7.eu/

[Ignacio Martin Llorente]

Hi,

As core partner in RESERVOIR, we will be happy to answer any question
related to this research and development effort.

Regards

--
Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente
and blog http://imllorente.dsa-research.org
DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

[Reuven Cohen]

On Tue, Jan 27, 2009 at 10:25 AM, Ignacio Martin Llorente
<llor...@dacya.ucm.es> wrote:
>
> Hi,
>
> As core partner in RESERVOIR, we will be happy to answer any question
> related to this research and development effort.
>
> Regards
>
> --
> Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente
> and blog http://imllorente.dsa-research.org
> DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org
> Globus GridWay Metascheduler: http://www.GridWay.org
> OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>
>
>
>
>
>

Count me in as well.

r/c

[Andy Edmonds]

So I finally got thoughts collected on our (SLA@SOI) thoughts and
experiences with XMPP to date. The article can be viewed here:

http://feeds.feedburner.com/~r/slasoi/~3/533312407/

Andy

On Jan 26, 11:39 am, Andy Edmonds <andy.edmo...@gmail.com> wrote:
> Hi Sal,
> I'm currently collecting and summarising our experiences with XMPP (which
> are far from over) and will post them up to the group.
>
> Andy
> andy.edmonds.be
>
> On Sat, Jan 24, 2009 at 21:12, sal <salvatore.lor...@ieee.org> wrote:
>
> > Hi Andy,
>
> > I have had a quickly look to the project site and the slides,
> > it looks extremely interesting!
>
> > About the XMPP experimenting you have performed
> > do you have any results , questions, doubts, or impression to share?
>
> > cheers
> > Sal

[Reuven Cohen]

This is a great overview.

Reuven

[tmor...@gmail.com]

Nice overview, Andy, and one we at Engine Yard largely agree on. XMPP
rocks!

You may be interested in discussing XMPP PubSub with Jayson.

Also, thanks for the inclusion of Vertebra, though it seems you think
it may be an XMPP server itself, whereas it's actually a application
platform atop XMPP, much like your work combined with the efforts of
RESEVOIR, unless I'm mistaken about your groups' work.

We believe that ejabberd is quite an impressive distributed XMPP
server, which you mention that you haven't found, so I thought I'd
pass that info along.

[Andy Edmonds]

Hey - Thanks guys :-) Would be cool if you could leave comments on the article too. I've updated the article to better reflect what Vertebra (apologies guys) is. Also, I was incorrect in what I called distributed - what I in fact meant was decentralised (in the mode of self-org P2P). We'd be hugely interested in talking with Jayson also on PubSub as I'm sure quite a number of people on the list would also.

With respect to SLA@SOI and RESERVOIR, I think it's fair to say that although complimentary our efforts are currently on parallel tracks but will hopefully in the near future will touch at useful and benificial "integration points".

Andy
andy.edmonds.be