XMPP is too stuffy
57 views
Skip to first unread message
JM
Mar 7, 2009, 6:30:04 AM3/7/09
to Cloud Computing Interoperability Forum (CCIF)
working many protocols over the years i.e SNMP, JMX and other
proprietary protocols complexity has always been an issue to support
in a continues changing environment. To support more interoperability
I recommend using SEMP (Simple Event Management Protocol ).
http://code.google.com/p/opensemp. This has a canned set of parameters
that vendors can subscribe to and are able to support long term the
mission to provide interoperability between clouds.
JM
proprietary protocols complexity has always been an issue to support
in a continues changing environment. To support more interoperability
I recommend using SEMP (Simple Event Management Protocol ).
http://code.google.com/p/opensemp. This has a canned set of parameters
that vendors can subscribe to and are able to support long term the
mission to provide interoperability between clouds.
JM
MS
Mar 7, 2009, 6:58:38 AM3/7/09
to cloud...@googlegroups.com
Hello Jason,
can you tell us more about the state of your proposed "standard"?
Thank you,
Martin
can you tell us more about the state of your proposed "standard"?
Thank you,
Martin
JM
Mar 7, 2009, 7:01:21 AM3/7/09
to Cloud Computing Interoperability Forum (CCIF)
Hello Martin,
The state is ready for cloud interoperability. Here is a live service
for SEMP.
http://service.utilitystatus.com/semp/services
Best Regards,
Jason
On Mar 7, 12:58 pm, MS <scho...@gmail.com> wrote:
> Hello Jason,
>
> can you tell us more about the state of your proposed "standard"?
>
> Thank you,
> Martin
>
The state is ready for cloud interoperability. Here is a live service
for SEMP.
http://service.utilitystatus.com/semp/services
Best Regards,
Jason
On Mar 7, 12:58 pm, MS <scho...@gmail.com> wrote:
> Hello Jason,
>
> can you tell us more about the state of your proposed "standard"?
>
> Thank you,
> Martin
>
Jayson Vantuyl
Mar 7, 2009, 8:14:03 PM3/7/09
to Cloud Computing Interoperability Forum (CCIF)
XMPP gives you a few really important things that SEMP doesn't. Most
importantly, it's a lot more NAT / firewall friendly. In an heavily
firewalled environment (and more poignantly between a number of
heavily firewalled environments simultaneously), you need more than a
host's IP address. XMPP is very good about this.
I completely agree that arbitrary data payloads make XMPP daunting
right now. On the Vertebra project, we decided to limit our data
payload to a hash, represented with the well known XML-RPC marshaling
format. With that restriction, it has been perhaps more tractable
that it otherwise might.
XMPP comes with a built-in, non-optional security mechanism. This is
really going to have to be a part of any Cloud. Passing around
authentication tokens is lovely and all, but having it at the
transport level just makes a lot more sense. After all, it's what
HTTP does. XMPP just makes it a bit easier to work with because it's
not optional, not an afterthought, and uniformly accessible without
regard to which server you're using (e.g. extending HTTP auth isn't
realistic given all the servers out there).
Administering it at a network level is a lot more functional as well.
The peer-to-peer model of the cloud is nice, but the federated model
(i.e. XMPP, SMTP, et al.) is much more manageable. While it seems
paradoxical that a less direct system is more manageable, it turns out
that it divides the problem into "server to my client" and "server to
other server". In practice, it makes the process of solving problems
nicer, because communication is along the lines of "administrator-to-
administrator" and "administrator-to-their-user", not "administrator-
to-other-user". Additionally, it gives a point of control to
administrators that just doesn't exist in completely distributed
system.
The decision of XMPP to stick with an already well implemented
encoding is also another factor. New systems tend to invent new
encodings that are rarely necessary. SNMP, LDAP, X529, and other
standards are known today largely because ASN.1 provided a stable
encoding and let them move on to better things. It turns out, ASN.1
encodings are horribly difficult beasts. Eventually, text conventions
like HTTP took over largely because they weren't as unwieldy.
XMPP takes a middle-road on this that is particularly functional given
the availability of streaming XML encoders and decoders. How you can
see that as "proprietary protocol complexity" is a little beyond me.
Apparently, IETF standards are proprietary and widely available
interchange formats are issues. About the only complaint I can see is
that raw-XML is too flexible and parsing it is more complex that, say,
JSON. I don't particularly see that as a problem since only a fool
would be writing their own parser and any number of decent XML
marshaling formats have been available for a while. We haven't even
talked about internationalization, which is a whole different can of
worms.
OpenSEMP's only major benefit is radical simplicity. While that is a
big benefit, it doesn't tackle the problems available in a diverse
cloud infrastructure. It won't without growing some sophistication,
which shouldn't be confused with mere complexity. Sophistication has
purpose.
importantly, it's a lot more NAT / firewall friendly. In an heavily
firewalled environment (and more poignantly between a number of
heavily firewalled environments simultaneously), you need more than a
host's IP address. XMPP is very good about this.
I completely agree that arbitrary data payloads make XMPP daunting
right now. On the Vertebra project, we decided to limit our data
payload to a hash, represented with the well known XML-RPC marshaling
format. With that restriction, it has been perhaps more tractable
that it otherwise might.
XMPP comes with a built-in, non-optional security mechanism. This is
really going to have to be a part of any Cloud. Passing around
authentication tokens is lovely and all, but having it at the
transport level just makes a lot more sense. After all, it's what
HTTP does. XMPP just makes it a bit easier to work with because it's
not optional, not an afterthought, and uniformly accessible without
regard to which server you're using (e.g. extending HTTP auth isn't
realistic given all the servers out there).
Administering it at a network level is a lot more functional as well.
The peer-to-peer model of the cloud is nice, but the federated model
(i.e. XMPP, SMTP, et al.) is much more manageable. While it seems
paradoxical that a less direct system is more manageable, it turns out
that it divides the problem into "server to my client" and "server to
other server". In practice, it makes the process of solving problems
nicer, because communication is along the lines of "administrator-to-
administrator" and "administrator-to-their-user", not "administrator-
to-other-user". Additionally, it gives a point of control to
administrators that just doesn't exist in completely distributed
system.
The decision of XMPP to stick with an already well implemented
encoding is also another factor. New systems tend to invent new
encodings that are rarely necessary. SNMP, LDAP, X529, and other
standards are known today largely because ASN.1 provided a stable
encoding and let them move on to better things. It turns out, ASN.1
encodings are horribly difficult beasts. Eventually, text conventions
like HTTP took over largely because they weren't as unwieldy.
XMPP takes a middle-road on this that is particularly functional given
the availability of streaming XML encoders and decoders. How you can
see that as "proprietary protocol complexity" is a little beyond me.
Apparently, IETF standards are proprietary and widely available
interchange formats are issues. About the only complaint I can see is
that raw-XML is too flexible and parsing it is more complex that, say,
JSON. I don't particularly see that as a problem since only a fool
would be writing their own parser and any number of decent XML
marshaling formats have been available for a while. We haven't even
talked about internationalization, which is a whole different can of
worms.
OpenSEMP's only major benefit is radical simplicity. While that is a
big benefit, it doesn't tackle the problems available in a diverse
cloud infrastructure. It won't without growing some sophistication,
which shouldn't be confused with mere complexity. Sophistication has
purpose.
Reuven Cohen
Mar 7, 2009, 9:17:43 PM3/7/09
to cloud...@googlegroups.com
interesting idea, but I'm not sure how your idea fits into the big
picture for an interoperable cloud environment. Maybe you could
outline some of the problems it solves.
As a side note we've been tossing around the idea of doing an SNMP
extension for UCI. We'd love to have you involved, your SEMP concept
seems like a great fit, and you obviously share our passion.
r/c
Jason N. Meiers
Mar 8, 2009, 4:37:12 AM3/8/09
to cloud...@googlegroups.com
@Jayson
The proxy for consolidating ACL change requersst is nessesary and an extension that will benefit SEMP. That being said, SEMP changes are built based on requirements for Cloud Computing specifically not Jabber or other non-cloud computing specific requirments.
Major benefits for using SEMP opposed to SNMP or XMPP
- Simple
- Fixed parameters ( Vendors cater to IT Administrators not the other way around i.e SNMP or JMX , XMPP )
- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications.
The only major benefit for XMPP is that larger companies are pushing it.
- Google
- Jabber
@Ruven
Fixed parameters for event management is critical for IT admins for infrastructure-as-a-service since the expectations of vendors categorizing application, system, network, database and transaction events correctly is very low without a standard rather than an (X) extended parameter set.
In addtion developers almost never include SNMP agents or JMX agents into production applications. This has multiple reasons, one: to difficult, two: developers don't care, three: time constraints. This is the last part in engineering if done at all, the simpler the better.
There could be a minimum set of SEMP required i.e at least two to notify if a component is up/down. This information is never straight forward in SNMP or XMPP since they are extendable and overblown to cater to multipurpose applications and not clouds.
Best Regards,
Jason
MS
Mar 8, 2009, 5:39:12 AM3/8/09
to cloud...@googlegroups.com
Hello Jason,
honestly, I like your "simple is beautiful" approach. I'm afraid, the
ISP / cloud / <whatever new buzzword might come up> is sadly more
complex and more "management-driven":
On Sun, Mar 8, 2009 at 9:37 AM, Jason N. Meiers <jason....@gmail.com> wrote:
> @Jayson
>
> The proxy for consolidating ACL change requersst is nessesary and an
> extension that will benefit SEMP. That being said, SEMP changes are built
> based on requirements for Cloud Computing specifically not Jabber or other
> non-cloud computing specific requirments.
>
> Major benefits for using SEMP opposed to SNMP or XMPP
>
> - Simple
> - Fixed parameters ( Vendors cater to IT Administrators not the other way
> around i.e SNMP or JMX , XMPP )
> - Protocol implementation changes are dictated by cloud requriments not
> Google, Jabber or for other multipurpose applications.
>
>
> The only major benefit for XMPP is that larger companies are pushing it.
>
> - Google
> - Jabber
The ISPs we work with already use XMPP and are really happy with it. I
cannot see a real need to change their way of doing their's everyday
business.
Even more, telling them to use "yet another infrastructure" only makes
sense if there were no alternatives. But there proven (!) alternatives
for what you do (realtime messaging): XMPP was made for RTM, and the
whole XMPP stack is mature. I regard these arguments as important for
each company doing serious cloud-related business.
Furthermore, I see no value in having yet another standard for
realtime messaging. Sorry.
>
> @Ruven
>
> Fixed parameters for event management is critical for IT admins for
> infrastructure-as-a-service since the expectations of vendors categorizing
> application, system, network, database and transaction events correctly is
> very low without a standard rather than an (X) extended parameter set.
Is this an argument for using XMPP for msg data transport? (That's my
interpretation btw).
>
> In addtion developers almost never include SNMP agents or JMX agents into
> production applications. This has multiple reasons, one: to difficult, two:
> developers don't care, three: time constraints. This is the last part in
> engineering if done at all, the simpler the better.
Agreed! But that's a completely different problem domain -- and your
way of solving it by proposing a new standard just doesn't fix it
(!!!).
>
> There could be a minimum set of SEMP required i.e at least two to notify if
> a component is up/down. This information is never straight forward in SNMP
> or XMPP since they are extendable and overblown to cater to multipurpose
> applications and not clouds.
Though I'm not an XMPP evangelist, please be so kind and describe what
you mean with "overblown"?
Martin
Jason N. Meiers
Mar 8, 2009, 5:41:27 AM3/8/09
to cloud...@googlegroups.com
Hello MS,
interesting, please provide an example for more management-driven.
Jason
interesting, please provide an example for more management-driven.
Jason
MS
Mar 8, 2009, 5:45:16 AM3/8/09
to cloud...@googlegroups.com
Hello Jason,
e.g. T-Systems.
Their decisions are typically made on a basis like "how can we manage
risk X" or "how much money will we loose if those 4000 call-center
agents cannot access the webapp". Speaking of cloud providers: "does
it scale and how much ressources will it take" are in lesser way also
"management decisions" that have a solely economical background, and
technical aspects matter less for the "decision makers".
Martin
e.g. T-Systems.
Their decisions are typically made on a basis like "how can we manage
risk X" or "how much money will we loose if those 4000 call-center
agents cannot access the webapp". Speaking of cloud providers: "does
it scale and how much ressources will it take" are in lesser way also
"management decisions" that have a solely economical background, and
technical aspects matter less for the "decision makers".
Martin
Jason N. Meiers
Mar 8, 2009, 6:05:35 AM3/8/09
to cloud...@googlegroups.com
Hello Martin,
For retail, banking, insurance and government it is important keep systems available since the transaction value is high in most cases and therefore a need for a standard that is simple and easy to implement and maintain from an administrators view. A T-Systems or Deutsche Telekom outage these days in nothing new. An example for this is Medicare at the Social Security Administration if these transaction don't come through there are actual people on the other end of the line waiting for money for medicine. Basically life and death. This is where the simplicity for SEMP adds more value than just support for Vendor A,B and C.
At the end of the day if management decides on a protocol the actual implementation is dependent on developers and IT administrators and not management or vendors such as Cisco or HP. The question I have for you is how can you support a protocol that is more vendor agnostic than IT admin or developer the people who actually use the product. Those guys have enough on their plate anyways with 24x7 without having to change IT management processes and event rules based on a new release from a Cisco router.
The recommendation with SEMP is to provide a protocol that vendors cater to not the other way around. Providing IT admins better support than vendors with improve the quaility of all servicecs including insurance, health care, banking, and telekoms.
With these vendors financing XMPP there is no intent to improve the quality for IT administrators your service but rather thier devices.
Jason
For retail, banking, insurance and government it is important keep systems available since the transaction value is high in most cases and therefore a need for a standard that is simple and easy to implement and maintain from an administrators view. A T-Systems or Deutsche Telekom outage these days in nothing new. An example for this is Medicare at the Social Security Administration if these transaction don't come through there are actual people on the other end of the line waiting for money for medicine. Basically life and death. This is where the simplicity for SEMP adds more value than just support for Vendor A,B and C.
At the end of the day if management decides on a protocol the actual implementation is dependent on developers and IT administrators and not management or vendors such as Cisco or HP. The question I have for you is how can you support a protocol that is more vendor agnostic than IT admin or developer the people who actually use the product. Those guys have enough on their plate anyways with 24x7 without having to change IT management processes and event rules based on a new release from a Cisco router.
The recommendation with SEMP is to provide a protocol that vendors cater to not the other way around. Providing IT admins better support than vendors with improve the quaility of all servicecs including insurance, health care, banking, and telekoms.
With these vendors financing XMPP there is no intent to improve the quality for IT administrators your service but rather thier devices.
XMPP Sponsors
Jason
MS
Mar 8, 2009, 6:16:40 AM3/8/09
to cloud...@googlegroups.com
Hello Jason,
[btw I hope you didn't miss the other parts of my pre-previous message].
On Sun, Mar 8, 2009 at 11:05 AM, Jason N. Meiers <jason....@gmail.com> wrote:
> Hello Martin,
>
> For retail, banking, insurance and government it is important keep systems
> available since the transaction value is high in most cases and therefore a
> need for a standard that is simple and easy to implement and maintain from
> an administrators view. A T-Systems or Deutsche Telekom outage these days in
> nothing new. An example for this is Medicare at the Social Security
> Administration if these transaction don't come through there are actual
> people on the other end of the line waiting for money for medicine.
> Basically life and death. This is where the simplicity for SEMP adds more
> value than just support for Vendor A,B and C.
>
> At the end of the day if management decides on a protocol the actual
> implementation is dependent on developers and IT administrators and not
> management or vendors such as Cisco or HP. The question I have for you is
> how can you support a protocol that is more vendor agnostic than IT admin or
> developer the people who actually use the product. Those guys have enough on
> their plate anyways with 24x7 without having to change IT management
> processes and event rules based on a new release from a Cisco router.
>
> The recommendation with SEMP is to provide a protocol that vendors cater to
> not the other way around. Providing IT admins better support than vendors
> with improve the quaility of all servicecs including insurance, health care,
> banking, and telekoms.
>
> With these vendors financing XMPP there is no intent to improve the quality
> for IT administrators your service but rather thier devices.
And you are not yet another vendor?
I visited your website and regard your arguments as a contradiction in
themself.
Just my 2 cents,
Martin
Jason N. Meiers
Mar 8, 2009, 6:23:49 AM3/8/09
to cloud...@googlegroups.com
If you want to talk about me send me an email offline, I am glad to answer you questions.
Why I support SEMP, I saw a need in the cloud to simplfy Cloud Event Management. With my stimulus check in 2008 I started SEMP and will donate for something to improve the quality of the IT admins life and the actual servcie not vendors. Please see my blog post from 2008.
http://www.camsolutionsinc.com/Blog/bid/5778/Cloud-Standards-Event-Management-and-Cloud-Autonomics
"I am just a monitoring person who is interested to help make positive change to get applications into the cloud and more manageable when more and more business applications get here, since these tasks will be on the IT management guys and my plate anyways thats why I put my stimulus check towards writting and submitting a patent for cloud event management, SEMP ( Simple Event Management Protocol )."
Best Regards,
Jason
Why I support SEMP, I saw a need in the cloud to simplfy Cloud Event Management. With my stimulus check in 2008 I started SEMP and will donate for something to improve the quality of the IT admins life and the actual servcie not vendors. Please see my blog post from 2008.
http://www.camsolutionsinc.com/Blog/bid/5778/Cloud-Standards-Event-Management-and-Cloud-Autonomics
"I am just a monitoring person who is interested to help make positive change to get applications into the cloud and more manageable when more and more business applications get here, since these tasks will be on the IT management guys and my plate anyways thats why I put my stimulus check towards writting and submitting a patent for cloud event management, SEMP ( Simple Event Management Protocol )."
Best Regards,
Jason
Ralph Biesemeyer
Mar 8, 2009, 9:38:42 AM3/8/09
to cloud...@googlegroups.com
This is a very interesting thread and I feel compelled to contribute my opinion.
Cloud comes from the realization that IT resources can be abstracted, but Cloud cannot exist without those resources. As I draw the generalized Cloud stack, I separate a Service Layer from an Infrastructure layer. We need "interoperability" where the layers meet. IT Admins at the Infrastructure layer must have efficient handles on the resources they are managing. At the Service layer above, Service Administrators need business justification for their policies and practices.
Perhaps both protocols, XMPP managing at the Service layer, and SEMP at the Infrastructure layer, would enable an efficient top to bottom management and reporting structure. If SEMP can make infrastructure more efficient and reduce costs, there may be no reason to impose an extensible protocol where it may not be needed. Problem is, device manufacturers also need to support legacy business structures which do not abstract IT resources.
The protocol-type decision should boil down to whether you are managing data resources or physical resources. As Martin notes, ISP management is working at the Service layer, making business decisions in real time if possible. As Jason argues, if IT managers find that SEMP enables more rapid, flexible and reliable changes (than XMPP) to infrastructure, they should use it. As Cloud services become prevalent, Service managers will not be making technical decisions on the infrastructure they use. They will make infrastructure business decisions and write an SLA in extensible business terms. It will be up to IT managers to decide if their Infrastructure can support the SLA or not.
Ralph
tluk...@exnihilum.com
Mar 7, 2009, 11:52:43 AM3/7/09
to cloud...@googlegroups.com
>> "The state is ready for cloud interoperability."
Whoa! I'll side-step the piles of naivete and hubris left by that statement (for now) and simply ask: "Where's the code?"There are no downloads listed at the site ( http://code.google.com/p/opensemp ) and (based on browsing it and attempting a code checkout) the Subversion repository is empty. Can you explain what your intention was in directing us to that site? Hopefully not the 1/2 page of "description", so while you're at it can you give us a link to some documentation? A "Cloud ready" project ought to have something other than a 1/2 page description.
I have a ton of questions and concerns, but perhaps reviewing the code and documentation will address some of them.
TL
-----Original Message-----
From: "JM" [jason....@gmail.com]
Date: 03/07/2009 07:01 AM
To: "Cloud Computing Interoperability Forum (CCIF)" <cloud...@googlegroups.com>
Subject: Re: XMPP is too stuffy
Hello Martin,
The state is ready for cloud interoperability. Here is a live service
for SEMP.
http://service.utilitystatus.com/semp/services
Best Regards,
Jason
On Mar 7, 12:58 pm, MS <scho...@gmail.com> wrote:
> Hello Jason,
>
> can you tell us more about the state of your proposed "standard"?
>
> Thank you,
> Martin
>
JM
Mar 8, 2009, 1:17:32 PM3/8/09
to Cloud Computing Interoperability Forum (CCIF)
@Ralph
agree, at the infrastruce-as-a-service layer it helps to provide
visibilty into components such as application, database, transaction
and web layer that scale. These events from semp can be correlated to
support the availbility of a service. For example, you get many semp
events from the database that a table space is full as well as semp
events from the application server that method insertData() is
throwing an exception. receiveng semp events at the transaction level
help to corrate which service and customer was affected by the
tablespace incident. Bring each of these together in rules or simple
views helps to quickly debug production incidents for IT
administrators. This ultimatly reduces cost for finding the issue as
well as provides a canned set of variables that vendors can subscribe
to rather than having to change rules and problem determinations
processes for production.
Jason
> >> Martin- Hide quoted text -
>
> - Show quoted text -
agree, at the infrastruce-as-a-service layer it helps to provide
visibilty into components such as application, database, transaction
and web layer that scale. These events from semp can be correlated to
support the availbility of a service. For example, you get many semp
events from the database that a table space is full as well as semp
events from the application server that method insertData() is
throwing an exception. receiveng semp events at the transaction level
help to corrate which service and customer was affected by the
tablespace incident. Bring each of these together in rules or simple
views helps to quickly debug production incidents for IT
administrators. This ultimatly reduces cost for finding the issue as
well as provides a canned set of variables that vendors can subscribe
to rather than having to change rules and problem determinations
processes for production.
Jason
> On Sun, Mar 8, 2009 at 3:23 AM, Jason N. Meiers <jason.mei...@gmail.com>wrote:
>
>
>
> > If you want to talk about me send me an email offline, I am glad to answer
> > you questions.
>
> > Why I support SEMP, I saw a need in the cloud to simplfy Cloud Event
> > Management. With my stimulus check in 2008 I started SEMP and will donate
> > for something to improve the quality of the IT admins life and the actual
> > servcie not vendors. Please see my blog post from 2008.
>
> >http://www.camsolutionsinc.com/Blog/bid/5778/Cloud-Standards-Event-Ma...
>
>
>
> > If you want to talk about me send me an email offline, I am glad to answer
> > you questions.
>
> > Why I support SEMP, I saw a need in the cloud to simplfy Cloud Event
> > Management. With my stimulus check in 2008 I started SEMP and will donate
> > for something to improve the quality of the IT admins life and the actual
> > servcie not vendors. Please see my blog post from 2008.
>
>
> > "I am just a monitoring person who is interested to help make positive
> > change to get applications into the cloud and more manageable when more and
> > more business applications get here, since these tasks will be on the IT
> > management guys and my plate anyways thats why I put my stimulus check
> > towards writting and submitting a patent for cloud event management, SEMP (
> > Simple Event Management Protocol )."
>
> > Best Regards,
> > Jason
>
> > "I am just a monitoring person who is interested to help make positive
> > change to get applications into the cloud and more manageable when more and
> > more business applications get here, since these tasks will be on the IT
> > management guys and my plate anyways thats why I put my stimulus check
> > towards writting and submitting a patent for cloud event management, SEMP (
> > Simple Event Management Protocol )."
>
> > Best Regards,
> > Jason
>
> > On Sun, Mar 8, 2009 at 11:16 AM, MS <scho...@gmail.com> wrote:
>
> >> Hello Jason,
>
> >> [btw I hope you didn't miss the other parts of my pre-previous message].
>
> >> On Sun, Mar 8, 2009 at 11:05 AM, Jason N. Meiers <jason.mei...@gmail.com>
>
> >> Hello Jason,
>
> >> [btw I hope you didn't miss the other parts of my pre-previous message].
>
>
> - Show quoted text -
tluk...@exnihilum.com
Mar 8, 2009, 4:03:27 PM3/8/09
to cloud...@googlegroups.com
>> "- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications."
>> "SEMP changes are built based on requirements for Cloud Computing specifically"
Jason,Can you please provide us with or point us to the definitive list of "requirements" that you've based SEMP's protocol(s) and parameter(s) on? Since you've repeatedly referred to these "Cloud specific requirements" I expect that they're concrete and expressible, and useful for evaluating SEMP and understanding some of the design decisions that you've made.
Thanks,
TL
-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/08/2009 04:37 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy
@Jayson
The proxy for consolidating ACL change requersst is nessesary and an extension that will benefit SEMP. That being said, SEMP changes are built based on requirements for Cloud Computing specifically not Jabber or other non-cloud computing specific requirments.
Major benefits for using SEMP opposed to SNMP or XMPP
- Simple
- Fixed parameters ( Vendors cater to IT Administrators not the other way around i.e SNMP or JMX , XMPP )
- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications.
The only major benefit for XMPP is that larger companies are pushing it.
- Google
- Jabber
The proxy for consolidating ACL change requersst is nessesary and an extension that will benefit SEMP. That being said, SEMP changes are built based on requirements for Cloud Computing specifically not Jabber or other non-cloud computing specific requirments.
Major benefits for using SEMP opposed to SNMP or XMPP
- Simple
- Fixed parameters ( Vendors cater to IT Administrators not the other way around i.e SNMP or JMX , XMPP )
- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications.
The only major benefit for XMPP is that larger companies are pushing it.
- Jabber
@Ruven
Fixed parameters for event management is critical for IT admins for infrastructure-as-a-service since the expectations of vendors categorizing application, system, network, database and transaction events correctly is very low without a standard rather than an (X) extended parameter set.
In addtion developers almost never include SNMP agents or JMX agents into production applications. This has multiple reasons, one: to difficult, two: developers dont care, three: time constraints. This is the last part in engineering if done at all, the simpler the better. Fixed parameters for event management is critical for IT admins for infrastructure-as-a-service since the expectations of vendors categorizing application, system, network, database and transaction events correctly is very low without a standard rather than an (X) extended parameter set.
There could be a minimum set of SEMP required i.e at least two to notify if a component is up/down. This information is never straight forward in SNMP or XMPP since they are extendable and overblown to cater to multipurpose applications and not clouds.
Jason
On Sat, Mar 7, 2009 at 6:30 AM, JM <jason....@gmail.com> wrote:
>
> working many protocols over the years i.e SNMP, JMX and other
> proprietary protocols complexity has always been an issue to support
> in a continues changing environment. To support more interoperability
> I recommend using SEMP (Simple Event Management Protocol ).
> http://code.google.com/p/opensemp. This has a canned set of parameters
> that vendors can subscribe to and are able to support long term the
> mission to provide interoperability between clouds.
>
> JM
> >
>
>
> working many protocols over the years i.e SNMP, JMX and other
> proprietary protocols complexity has always been an issue to support
> in a continues changing environment. To support more interoperability
> I recommend using SEMP (Simple Event Management Protocol ).
> http://code.google.com/p/opensemp. This has a canned set of parameters
> that vendors can subscribe to and are able to support long term the
> mission to provide interoperability between clouds.
>
> JM
> >
>
@JM, could you outline some use cases for us? Sounds like an
interesting idea, but Im not sure how your idea fits into the bigpicture for an interoperable cloud environment. Maybe you could
outline some of the problems it solves.
extension for UCI. Wed love to have you involved, your SEMP concept
Sam Johnston
Mar 8, 2009, 4:42:08 AM3/8/09
to cloud...@googlegroups.com
Jason,
What you fail to mention about this unknown protocol that you "recommend" is that it is yours. I fail to see how this is even in the same league as the well established XMPP standard and at least some of us have been working on XMPP projects relating to cloud computing since long before even CCIF existed so I don't know what makes you think you might be able to change that now, no matter how much you spam cloud groups. Where's the standard? Reference implementations? Patent pledges? Is it just me or is the Google Code project you refer to completely empty? The (soon to be deleted) Wikipedia article you created on the subject isn't much better and your leading assertion that "Simple Event Management Protocol (SEMP) is a component of the Internet Protocol Suite" is, to be frank, laughable.
I can't help but to notice that you happen to be offering a commercial SEMP service at UtilityStatus (somewhat the conflict of interest wouldn't you say?), and that your only listed client, CloudAutonomics, happens also to be you! I see that CloudAssets and CloudRequest are you too, as is CAM Solutions. What I don't see is tangible products, or in this case, protocols.
Anyway I don't so much care for your various endeavours but I do care passionately about IP abuse (see here and here), which is why I find your recently registered trademark (#77484486) for "monitoring-as-a-service" rather offensive. You're no doubt aware my TrustSaaS service which also falls into this category (but which is not marketed as such given my disdain for *aaS), and of the various others such as RedHat (which are, and who beat you to it by a year or two by the way). Indeed you took the liberty of removing them all when you hijacked Wikipedia's monitoring as a service article shortly after your questionable trademark was issued; it seems you believe that this gives you the right to hijack articles but as you will soon see, it most certainly does not. I also have plenty of better things to do with my Sunday morning than clean up after spammers.
In summary, given your recent shenanigans with intellectual property abuse I don't see any reason why your commercially-driven "protocol" should get any more discussion than it already has (which, incidentally, is probably more than it ever deserved).
Cheers,
Sam
What you fail to mention about this unknown protocol that you "recommend" is that it is yours. I fail to see how this is even in the same league as the well established XMPP standard and at least some of us have been working on XMPP projects relating to cloud computing since long before even CCIF existed so I don't know what makes you think you might be able to change that now, no matter how much you spam cloud groups. Where's the standard? Reference implementations? Patent pledges? Is it just me or is the Google Code project you refer to completely empty? The (soon to be deleted) Wikipedia article you created on the subject isn't much better and your leading assertion that "Simple Event Management Protocol (SEMP) is a component of the Internet Protocol Suite" is, to be frank, laughable.
I can't help but to notice that you happen to be offering a commercial SEMP service at UtilityStatus (somewhat the conflict of interest wouldn't you say?), and that your only listed client, CloudAutonomics, happens also to be you! I see that CloudAssets and CloudRequest are you too, as is CAM Solutions. What I don't see is tangible products, or in this case, protocols.
Anyway I don't so much care for your various endeavours but I do care passionately about IP abuse (see here and here), which is why I find your recently registered trademark (#77484486) for "monitoring-as-a-service" rather offensive. You're no doubt aware my TrustSaaS service which also falls into this category (but which is not marketed as such given my disdain for *aaS), and of the various others such as RedHat (which are, and who beat you to it by a year or two by the way). Indeed you took the liberty of removing them all when you hijacked Wikipedia's monitoring as a service article shortly after your questionable trademark was issued; it seems you believe that this gives you the right to hijack articles but as you will soon see, it most certainly does not. I also have plenty of better things to do with my Sunday morning than clean up after spammers.
In summary, given your recent shenanigans with intellectual property abuse I don't see any reason why your commercially-driven "protocol" should get any more discussion than it already has (which, incidentally, is probably more than it ever deserved).
Cheers,
Sam
On Sat, Mar 7, 2009 at 12:30 PM, JM <jason....@gmail.com> wrote:
Jason N. Meiers
Mar 8, 2009, 7:04:34 PM3/8/09
to cloud...@googlegroups.com
Sam, whatever dude.
Paul Borrill
Mar 8, 2009, 9:56:58 PM3/8/09
to cloud...@googlegroups.com
Sam, Bravo. Clean, factual, professional. Well done.
Paul
Dr. Paul Borrill
Jason N. Meiers
Mar 9, 2009, 4:44:54 AM3/9/09
to cloud...@googlegroups.com
Sam, it sounds like you need a huge.
Jason
Jayson Vantuyl
Mar 9, 2009, 8:01:58 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
@JM
Wow. I tried really hard to give you a chance. I guess that's over.
"Dude whatever" is not a dignified response. There is nothing about
Sam's post that deserves that disrespect. And "You need a hug"...
Are we on X-Box live? Condescending trash-talking? This is entirely
inappropriate in a discussion between professionals.
I could take any number of cheaper shots, but let me focus on the
fruits of your years of experience in "IT". You do realize that
you've effectively invented little more than syslog with a few more
fields? It's kind of like the mutant stepchild of syslog and NT's
eventlog--something which we will give a quick death if we have any
mercy and humanity in our souls. It is interesting neither from an
operational nor technological standpoint.
Please take your SEMP elsewhere. We don't need another standard.
Yours appears to be little more than a non-extensible, key-value hash
pushed over a TCP connection. We could just download redis from
Google Code and already having something that is better featured, more
fully implemented, more fully deployed, has a bigger community, more
resembles a standard, and is less likely to illegitimately attempt to
profit from other people's hard work.
In short, please go away. You have worn out your welcome. You and
your kind embodies all that is wrong with my industry, and I dislike
you strongly for it.
@SamJ:
You seem to have hit the nail on the head. Thanks for submitting his
page for speedy deletion. It appears that Wikipedia agrees with you.
His linkedin profile (at least currently) lists Patent Development.
That gets even scarier than just yet-another-aas-trademark.
He also apparently writes for SysCon, who are semi-infamous for being
the people who published most of the pro-SCO propaganda during the
early days of the trail--including the "expose" where a devious
reporter attempted to "unmask" Groklaw's PJ--by stalking her and her
family. Guilt by association, I guess.
If you read his "Cloud Computing: The On-Demand Model Has Been
Available for a While" article, you'll notice the same rambling style,
bouncing off of various buzzwords, without apparently saying too
much. Kind of like OpenSEMP. Lots of handwaving, a few buzzwords,
nothing inherently useful.
@Everybody else:
In the end, I guess he's comparing RFC 3920 and RFC 3921 to a largely
empty Google Code page, or a self-aggrandizing Wikipedia article.
Suddenly doesn't sound like much of a competition. This is kind of a
tragedy, since he apparently, in a single stroke, fails to appreciate
the function of Wikipedia, the dangers of imaginary property taken too
far, or even the basic nature of what purpose a standard would serve.
FAIL on all accounts.
It's clear that he's more than happy to commercialize the Cloud and
standards processes via oppressive IP maneuvers. I'll not be a party
to that. I suggest that further serious discussion of OpenSEMP be
tabled, and further mentions of it be concurrent with sarcasm,
snickering, and derisive laughter.
NOTE: I'm not even linking any of his stuff, just to prevent any
accidental boost to his PageRank. Also, any statements above are not
the opinions of my employer, but rather my own surly, personal,
distilled hatred.
Wow. I tried really hard to give you a chance. I guess that's over.
"Dude whatever" is not a dignified response. There is nothing about
Sam's post that deserves that disrespect. And "You need a hug"...
Are we on X-Box live? Condescending trash-talking? This is entirely
inappropriate in a discussion between professionals.
I could take any number of cheaper shots, but let me focus on the
fruits of your years of experience in "IT". You do realize that
you've effectively invented little more than syslog with a few more
fields? It's kind of like the mutant stepchild of syslog and NT's
eventlog--something which we will give a quick death if we have any
mercy and humanity in our souls. It is interesting neither from an
operational nor technological standpoint.
Please take your SEMP elsewhere. We don't need another standard.
Yours appears to be little more than a non-extensible, key-value hash
pushed over a TCP connection. We could just download redis from
Google Code and already having something that is better featured, more
fully implemented, more fully deployed, has a bigger community, more
resembles a standard, and is less likely to illegitimately attempt to
profit from other people's hard work.
In short, please go away. You have worn out your welcome. You and
your kind embodies all that is wrong with my industry, and I dislike
you strongly for it.
@SamJ:
You seem to have hit the nail on the head. Thanks for submitting his
page for speedy deletion. It appears that Wikipedia agrees with you.
His linkedin profile (at least currently) lists Patent Development.
That gets even scarier than just yet-another-aas-trademark.
He also apparently writes for SysCon, who are semi-infamous for being
the people who published most of the pro-SCO propaganda during the
early days of the trail--including the "expose" where a devious
reporter attempted to "unmask" Groklaw's PJ--by stalking her and her
family. Guilt by association, I guess.
If you read his "Cloud Computing: The On-Demand Model Has Been
Available for a While" article, you'll notice the same rambling style,
bouncing off of various buzzwords, without apparently saying too
much. Kind of like OpenSEMP. Lots of handwaving, a few buzzwords,
nothing inherently useful.
@Everybody else:
In the end, I guess he's comparing RFC 3920 and RFC 3921 to a largely
empty Google Code page, or a self-aggrandizing Wikipedia article.
Suddenly doesn't sound like much of a competition. This is kind of a
tragedy, since he apparently, in a single stroke, fails to appreciate
the function of Wikipedia, the dangers of imaginary property taken too
far, or even the basic nature of what purpose a standard would serve.
FAIL on all accounts.
It's clear that he's more than happy to commercialize the Cloud and
standards processes via oppressive IP maneuvers. I'll not be a party
to that. I suggest that further serious discussion of OpenSEMP be
tabled, and further mentions of it be concurrent with sarcasm,
snickering, and derisive laughter.
NOTE: I'm not even linking any of his stuff, just to prevent any
accidental boost to his PageRank. Also, any statements above are not
the opinions of my employer, but rather my own surly, personal,
distilled hatred.
Jason N. Meiers
Mar 9, 2009, 8:05:12 AM3/9/09
to cloud...@googlegroups.com
@Jayson
hold your horses adding the changes from utiltystatus to org.opensemp. upload in progress...
hold your horses adding the changes from utiltystatus to org.opensemp. upload in progress...
Egon Willighagen
Mar 9, 2009, 8:05:31 AM3/9/09
to cloud...@googlegroups.com
On Sat, Mar 7, 2009 at 12:30 PM, JM <jason....@gmail.com> wrote:
What is your opinion on XEP-0244 (IO-DATA)? Stuffy too? I'd say is has
a quite simple API, at least, that's what we tried.
Egon
--
Post-doc @ Uppsala University
http://chem-bla-ics.blogspot.com/
JM
Mar 9, 2009, 8:47:45 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
Egon, from experience in IT Operations it is very important to limit
unessary changes to production. If a new router or os update comes out
and they changed a snmp parameter that alert is not caught since the
rules for availability have changed. This ultimatly cause less sleep
as finding the problem before it occurs is challenging with constant
changing parameters. Basically these vendor changes cause production
outages for the business.
On 9 Mrz., 13:05, Egon Willighagen <egon.willigha...@gmail.com> wrote:
unessary changes to production. If a new router or os update comes out
and they changed a snmp parameter that alert is not caught since the
rules for availability have changed. This ultimatly cause less sleep
as finding the problem before it occurs is challenging with constant
changing parameters. Basically these vendor changes cause production
outages for the business.
On 9 Mrz., 13:05, Egon Willighagen <egon.willigha...@gmail.com> wrote:
Egon Willighagen
Mar 9, 2009, 8:48:58 AM3/9/09
to cloud...@googlegroups.com
On Mon, Mar 9, 2009 at 1:47 PM, JM <jason....@gmail.com> wrote:
> Egon, from experience in IT Operations it is very important to limit
> unessary changes to production. If a new router or os update comes out
> and they changed a snmp parameter that alert is not caught since the
> rules for availability have changed. This ultimatly cause less sleep
> as finding the problem before it occurs is challenging with constant
> changing parameters. Basically these vendor changes cause production
> outages for the business.
> Egon, from experience in IT Operations it is very important to limit
> unessary changes to production. If a new router or os update comes out
> and they changed a snmp parameter that alert is not caught since the
> rules for availability have changed. This ultimatly cause less sleep
> as finding the problem before it occurs is challenging with constant
> changing parameters. Basically these vendor changes cause production
> outages for the business.
So, what's your catch on IO-DATA then? No parameter have changed
there, and there are not so many anyway...
Egon
> On 9 Mrz., 13:05, Egon Willighagen <egon.willigha...@gmail.com> wrote:
>> On Sat, Mar 7, 2009 at 12:30 PM, JM <jason.mei...@gmail.com> wrote:
>> > working many protocols over the years i.e SNMP, JMX and other
>> > proprietary protocols complexity has always been an issue to support
>> > in a continues changing environment. To support more interoperability
>> > I recommend using SEMP (Simple Event Management Protocol ).
>> >http://code.google.com/p/opensemp. This has a canned set of parameters
>> > that vendors can subscribe to and are able to support long term the
>> > mission to provide interoperability between clouds.
>>
>> What is your opinion on XEP-0244 (IO-DATA)? Stuffy too? I'd say is has
>> a quite simple API, at least, that's what we tried.
Jason N. Meiers
Mar 9, 2009, 8:54:25 AM3/9/09
to cloud...@googlegroups.com
ok got the parameters fro XEP. looks good. one key parameter mission right off the bat. location, i.e cloud or datacenter. i could tell you a list of stories from vendors we evaluated who didnt have this.
<iodata xmlns='urn:xmpp:tmp:io-data'
type='transaction-type'>
<desc/>
<in/>
<out/>
<error/>
<status>
<elapsed/>
<remaining/>
<percentage/>
<information/>
</status>
</iodata>
type='transaction-type'>
<desc/>
<in/>
<out/>
<error/>
<status>
<elapsed/>
<remaining/>
<percentage/>
<information/>
</status>
</iodata>
Jason N. Meiers
Mar 9, 2009, 8:55:48 AM3/9/09
to cloud...@googlegroups.com
adding SEMP parameters here.. The location supports multiple clouds and data centers.
"description", => error codes
"group", => network, application, systems
"IP", => 172.29.131.5
"location", => cloud/subnet/datacenter
"severity", => 1,2,3,4,5
"source", => esm system, application, ...
"subsource", => transactions
"time", => unixtimestamp
"status", => open/closed/archived/pending
Egon Willighagen
Mar 9, 2009, 9:01:21 AM3/9/09
to cloud...@googlegroups.com
On Mon, Mar 9, 2009 at 1:54 PM, Jason N. Meiers <jason....@gmail.com> wrote:
> ok got the parameters fro XEP. looks good. one key parameter mission right
> off the bat. location, i.e cloud or datacenter. i could tell you a list of
> stories from vendors we evaluated who didnt have this.
> off the bat. location, i.e cloud or datacenter. i could tell you a list of
> stories from vendors we evaluated who didnt have this.
That's implied in the address to which you send the message...
discovery of services is done via the DISCO XEP.
Egon
JM
Mar 9, 2009, 9:24:16 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
the implied parameter approach is interesting although the location
parameter is required. without the need to be parsed or processed. The
value of this parameter is at the IT administrator level. Your
datacenter could be in NY or Sweden, to add addtional parsing for
implecit parameters at that level is a CPU consumer as well as general
process overhead .
On 9 Mrz., 14:01, Egon Willighagen <egon.willigha...@gmail.com> wrote:
parameter is required. without the need to be parsed or processed. The
value of this parameter is at the IT administrator level. Your
datacenter could be in NY or Sweden, to add addtional parsing for
implecit parameters at that level is a CPU consumer as well as general
process overhead .
On 9 Mrz., 14:01, Egon Willighagen <egon.willigha...@gmail.com> wrote:
Egon Willighagen
Mar 9, 2009, 9:31:08 AM3/9/09
to cloud...@googlegroups.com
On Mon, Mar 9, 2009 at 2:24 PM, JM <jason....@gmail.com> wrote:
> the implied parameter approach is interesting although the location
> parameter is required. without the need to be parsed or processed. The
> value of this parameter is at the IT administrator level. Your
> datacenter could be in NY or Sweden ... <snip>> the implied parameter approach is interesting although the location
> parameter is required. without the need to be parsed or processed. The
> value of this parameter is at the IT administrator level. Your
OK, you want to decide where a service is physically located too, not just IP...
Not sure of the current IO-DATA implementation (xws4j) supports it,
but there is XEP-0080:
http://xmpp.org/extensions/xep-0080.html
JM
Mar 9, 2009, 9:35:22 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
nice, this is specialized for geographical data to tell you where
soemthing is located on the planet. sweet.
althought its not cloud event management. the strong accent for lat
and long rather than severity, status or other event managenet related
figures.
<message from='por...@merchantofvenice.lit'
to='bass...@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
<item id='d81a52b8-0f9c-11dc-9bc8-001143d5d5db'>
<geoloc xmlns='http://jabber.org/protocol/geoloc'
xml:lang='en'>
<country>Italy</country>
<lat>45.44</lat>
<locality>Venice</locality>
<lon>12.33</lon>
<accuracy>20</accuracy>
</geoloc>
</item>
</items>
</event>
</message>
On 9 Mrz., 14:31, Egon Willighagen <egon.willigha...@gmail.com> wrote:
soemthing is located on the planet. sweet.
althought its not cloud event management. the strong accent for lat
and long rather than severity, status or other event managenet related
figures.
<message from='por...@merchantofvenice.lit'
to='bass...@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
<item id='d81a52b8-0f9c-11dc-9bc8-001143d5d5db'>
<geoloc xmlns='http://jabber.org/protocol/geoloc'
xml:lang='en'>
<country>Italy</country>
<lat>45.44</lat>
<locality>Venice</locality>
<lon>12.33</lon>
<accuracy>20</accuracy>
</geoloc>
</item>
</items>
</event>
</message>
On 9 Mrz., 14:31, Egon Willighagen <egon.willigha...@gmail.com> wrote:
Egon Willighagen
Mar 9, 2009, 9:38:35 AM3/9/09
to cloud...@googlegroups.com
On Mon, Mar 9, 2009 at 2:35 PM, JM <jason....@gmail.com> wrote:
> nice, this is specialized for geographical data to tell you where
> soemthing is located on the planet. sweet.
>
> althought its not cloud event management. the strong accent for lat
> and long rather than severity, status or other event managenet related
> figures.
> nice, this is specialized for geographical data to tell you where
> soemthing is located on the planet. sweet.
>
> althought its not cloud event management. the strong accent for lat
> and long rather than severity, status or other event managenet related
> figures.
This is something I like about XMPP, there is a solution to a lot of
things of the shelf. Glad to see you like it.
tluk...@exnihilum.com
Mar 9, 2009, 9:35:37 AM3/9/09
to cloud...@googlegroups.com
>> "specifically for cloud computing.."
There's that "Cloud specific" wording again.. which reminds me that you also haven't yet responded to my *other* request for the design data that you used to guide your "specialization" of SEMP for "the Cloud".
For your convenience I'll repeat that request here:
>> "- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications."
>> "SEMP changes are built based on requirements for Cloud Computing specifically"
Jason,
Can you please provide us with or point us to the definitive list of "requirements" that you've based SEMP's protocol(s) and parameter(s) on? Since you've repeatedly referred to these "Cloud specific requirements" I expect that they're concrete and expressible, and useful for evaluating SEMP and understanding some of the design decisions that you've made.
Thanks,
TL
-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/09/2009 09:13 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy
Paulo, agree there will always be a push for adding more variables as long as the mission statement stays the same, to provide a protocol for " IT administrators not vendors" we should be good. i.e. adding a counsel simular to SNMP would help if that is UCI or another. Since this protocol has been introced specifically for cloud computing at the infrastructure level UCI would be best IMHO.
..
..
-~----------~----~----~----~------~----~------~--~---
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
-----
Join our Twitter Group at www.twitter.com/cloudforum
Or Our Linkedin Group at http://www.linkedin.com/e/gis/927567
-~----------~----~----~----~------~----~------~--~---
There's that "Cloud specific" wording again.. which reminds me that you also haven't yet responded to my *other* request for the design data that you used to guide your "specialization" of SEMP for "the Cloud".
For your convenience I'll repeat that request here:
>> "- Protocol implementation changes are dictated by cloud requriments not Google, Jabber or for other multipurpose applications."
>> "SEMP changes are built based on requirements for Cloud Computing specifically"
Jason,
Can you please provide us with or point us to the definitive list of "requirements" that you've based SEMP's protocol(s) and parameter(s) on? Since you've repeatedly referred to these "Cloud specific requirements" I expect that they're concrete and expressible, and useful for evaluating SEMP and understanding some of the design decisions that you've made.
Thanks,
TL
-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/09/2009 09:13 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy
..
..
-~----------~----~----~----~------~----~------~--~---
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
-----
Join our Twitter Group at www.twitter.com/cloudforum
Or Our Linkedin Group at http://www.linkedin.com/e/gis/927567
-~----------~----~----~----~------~----~------~--~---
Jason N. Meiers
Mar 9, 2009, 9:42:28 AM3/9/09
to cloud...@googlegroups.com
yes there are alot of stuff of the shelf with XMPP just for IT administrators to difficult to implement and manage change compared to other protocols. xmpp is like c++ where semp would be a ruby. To manage changing IT environments .
Jason N. Meiers
Mar 9, 2009, 9:45:49 AM3/9/09
to cloud...@googlegroups.com
@TL
the requriements are from building a successful SaaS company tranforming traditional inhouse hosted software to SaaS on EC2
as well as from experice working in a 24x7 environment as IT administrator and understanding the challenges including sleepless nights due to events and alerts.
eprpa...@gmail.com
Mar 9, 2009, 9:53:25 AM3/9/09
to cloud...@googlegroups.com
I'm sorry I disagree. That statement is pure, unadulterated baloney.
C.
C.
Jason N. Meiers
Mar 9, 2009, 9:54:45 AM3/9/09
to cloud...@googlegroups.com
not so good stuff. please elaborate.
eprpa...@gmail.com
Mar 9, 2009, 9:57:37 AM3/9/09
to cloud...@googlegroups.com
Jason,
Just make your case for your "solution" and leave it to the list to
determine if it has any value. Stop trying to "sell" us on how smart you
are, how great you are or how successful you are. We will just evaluate
you proposal on how well it does what it is supposed to do and how it
stacks up to the other solutions out there.
C.
Jason N. Meiers wrote:
Just make your case for your "solution" and leave it to the list to
determine if it has any value. Stop trying to "sell" us on how smart you
are, how great you are or how successful you are. We will just evaluate
you proposal on how well it does what it is supposed to do and how it
stacks up to the other solutions out there.
C.
Jason N. Meiers wrote:
Jason N. Meiers
Mar 9, 2009, 9:58:52 AM3/9/09
to cloud...@googlegroups.com
As far as I understand this is a democracy, I can particiapte in the evaluation.
Peter Saint-Andre
Mar 9, 2009, 10:03:11 AM3/9/09
to cloud...@googlegroups.com
On 3/9/09 7:42 AM, Jason N. Meiers wrote:
> yes there are alot of stuff of the shelf with XMPP just for IT
> administrators to difficult to implement and manage change compared to
> other protocols. xmpp is like c++ where semp would be a ruby. To manage
> changing IT environments .
> yes there are alot of stuff of the shelf with XMPP just for IT
> administrators to difficult to implement and manage change compared to
> other protocols. xmpp is like c++ where semp would be a ruby. To manage
> changing IT environments .
<rant>
XMPP is a protocol. IT administrators do not implement protocols, they
deploy implementations of protocols, which are produced by software
developers. If your complaint against XMPP technologies is that the
existing software implementations can be difficult to deploy, then the
solution is not to throw out all of the work that has been done over the
last ten years to harden and secure XMPP's core layers and also develop
numerous extensions to that core. Instead, the solution is to build a
slimmed-down implementation in one of your preferred code languages.
Which XMPP implementations have you worked with? What did you find
difficult? Was it the servers that you found difficult? Did you have
problems working out how to use some of the libraries? Which ones? There
are XMPP libraries (and even servers) for Python, Ruby, Perl, and other
scripting languages, and those codebases generally make it pretty darn
easy to deploy services. That said, I'm sure that they could be improved
even further, so feel free to contribute.
No technology is perfect. XMPP is no exception. Instead of vague claims
that XMPP is "stuffy", you might provide concrete criticisms. Even
better, you might help out a team that is working on an XMPP
implementation in one of your favorite code languages by filing bug
reports, making feature requests, providing patches, and other such
productive contributions.
As to the charge of stuffiness, one of my dictionaries defines it as
"not receptive to new or unusual ideas and behavior; conventional and
narrow-minded". In fact the XMPP community is working on all sorts of
new, unconventional ideas, from location-based services to microblogging
and from multimedia collaboration to lightweight middleware. If you were
to participate in that community instead of sniping from the sidelines,
you might be surprised at how wrong you are.
Oh, and if you could construct just one grammatical sentence I might
take your messages more seriously.
</rant>
Peter
--
Peter Saint-Andre
https://stpeter.im/
eprpa...@gmail.com
Mar 9, 2009, 10:07:38 AM3/9/09
to cloud...@googlegroups.com
Please re-read what I said. State your case and the list (and as a
member that includes you) will decide the appropriateness and usefulness
of your proposal. But all the selling of how great you are, how
successful you are or how smart you are will not add anything to the
decision. It will be on its merits only. And be honest; now a days it is
too easy to figure out the charlatans. This wisdom comes from someone
that has been around for 30 years on the "network" and worked on many
standards and has been involved in the open source community before the FSF.
C.
Jason N. Meiers wrote:
> As far as I understand this is a democracy, I can particiapte in the
> evaluation.
>
> On Mon, Mar 9, 2009 at 2:57 PM, <eprpa...@gmail.com
> <mailto:eprpa...@gmail.com>> wrote:
>
>
> Jason,
>
> Just make your case for your "solution" and leave it to the list to
> determine if it has any value. Stop trying to "sell" us on how smart you
> are, how great you are or how successful you are. We will just evaluate
> you proposal on how well it does what it is supposed to do and how it
> stacks up to the other solutions out there.
>
> C.
>
> Jason N. Meiers wrote:
> > @TL
> >
> > the requriements are from building a successful SaaS company
> tranforming
> > traditional inhouse hosted software to SaaS on EC2
> > http://www.camsolutionsinc.com/
> >
> > as well as from experice working in a 24x7 environment as IT
> > administrator and understanding the challenges including sleepless
> > nights due to events and alerts.
> >
> > On Mon, Mar 9, 2009 at 2:42 PM, Jason N. Meiers
> <jason....@gmail.com <mailto:jason....@gmail.com>
> > <mailto:jason....@gmail.com <mailto:jason....@gmail.com>>>
member that includes you) will decide the appropriateness and usefulness
of your proposal. But all the selling of how great you are, how
successful you are or how smart you are will not add anything to the
decision. It will be on its merits only. And be honest; now a days it is
too easy to figure out the charlatans. This wisdom comes from someone
that has been around for 30 years on the "network" and worked on many
standards and has been involved in the open source community before the FSF.
C.
Jason N. Meiers wrote:
> As far as I understand this is a democracy, I can particiapte in the
> evaluation.
>
> On Mon, Mar 9, 2009 at 2:57 PM, <eprpa...@gmail.com
> <mailto:eprpa...@gmail.com>> wrote:
>
>
> Jason,
>
> Just make your case for your "solution" and leave it to the list to
> determine if it has any value. Stop trying to "sell" us on how smart you
> are, how great you are or how successful you are. We will just evaluate
> you proposal on how well it does what it is supposed to do and how it
> stacks up to the other solutions out there.
>
> C.
>
> Jason N. Meiers wrote:
> > @TL
> >
> > the requriements are from building a successful SaaS company
> tranforming
> > traditional inhouse hosted software to SaaS on EC2
> > http://www.camsolutionsinc.com/
> >
> > as well as from experice working in a 24x7 environment as IT
> > administrator and understanding the challenges including sleepless
> > nights due to events and alerts.
> >
> > On Mon, Mar 9, 2009 at 2:42 PM, Jason N. Meiers
> <jason....@gmail.com <mailto:jason....@gmail.com>
> wrote:
> >
> > yes there are alot of stuff of the shelf with XMPP just for IT
> > administrators to difficult to implement and manage change
> compared
> > to other protocols. xmpp is like c++ where semp would be a
> ruby. To
> > manage changing IT environments .
> >
> > On Mon, Mar 9, 2009 at 2:38 PM, Egon Willighagen
> > <egon.wil...@gmail.com
> <mailto:egon.wil...@gmail.com>
> <mailto:egon.wil...@gmail.com
> >
> > yes there are alot of stuff of the shelf with XMPP just for IT
> > administrators to difficult to implement and manage change
> compared
> > to other protocols. xmpp is like c++ where semp would be a
> ruby. To
> > manage changing IT environments .
> >
> > On Mon, Mar 9, 2009 at 2:38 PM, Egon Willighagen
> > <egon.wil...@gmail.com
> <mailto:egon.wil...@gmail.com>
> <mailto:egon.wil...@gmail.com>>> wrote:
> >
> >
> > On Mon, Mar 9, 2009 at 2:35 PM, JM <jason....@gmail.com
> <mailto:jason....@gmail.com>
> > <mailto:jason....@gmail.com
> >
> >
> > On Mon, Mar 9, 2009 at 2:35 PM, JM <jason....@gmail.com
> <mailto:jason....@gmail.com>
JM
Mar 9, 2009, 10:08:06 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
good stuff. I am not a developer trying to solve the worlds problems,
just event management. xmpp is to entensible dont take it the wrong
way the technolgy is smooth and smart although to stuffy. the mindset
is for (X). for IT operations we need static to put the compliance for
productions applications in the shoes of the vendors not IT
administrators.
> smime.p7s
> 8KViewDownload
just event management. xmpp is to entensible dont take it the wrong
way the technolgy is smooth and smart although to stuffy. the mindset
is for (X). for IT operations we need static to put the compliance for
productions applications in the shoes of the vendors not IT
administrators.
> 8KViewDownload
eprpa...@gmail.com
Mar 9, 2009, 10:09:07 AM3/9/09
to cloud...@googlegroups.com
Thanks Peter. I was just going to answer his email but yours does so
beautifully.
beautifully.
Chuck Wegrzyn
JM
Mar 9, 2009, 10:09:57 AM3/9/09
to Cloud Computing Interoperability Forum (CCIF)
@eprparad
instead of adding to this thread about how the process is to be
dictated why not open a new thread off "XMPP is too stuffy"?
On Mar 9, 3:07 pm, eprparad...@gmail.com wrote:
> Please re-read what I said. State your case and the list (and as a
> member that includes you) will decide the appropriateness and usefulness
> of your proposal. But all the selling of how great you are, how
> successful you are or how smart you are will not add anything to the
> decision. It will be on its merits only. And be honest; now a days it is
> too easy to figure out the charlatans. This wisdom comes from someone
> that has been around for 30 years on the "network" and worked on many
> standards and has been involved in the open source community before the FSF.
>
> C.
>
>
>
> Jason N. Meiers wrote:
> > As far as I understand this is a democracy, I can particiapte in the
> > evaluation.
>
> > > <mailto:jason.mei...@gmail.com <mailto:jason.mei...@gmail.com>>>
> > <mailto:egon.willigha...@gmail.com>
> > <mailto:egon.willigha...@gmail.com
> > <mailto:egon.willigha...@gmail.com>>> wrote:
>
> > > On Mon, Mar 9, 2009 at 2:35 PM, JM <jason.mei...@gmail.com
> > <mailto:jason.mei...@gmail.com>
> > > <mailto:jason.mei...@gmail.com
>
> - Show quoted text -
instead of adding to this thread about how the process is to be
dictated why not open a new thread off "XMPP is too stuffy"?
On Mar 9, 3:07 pm, eprparad...@gmail.com wrote:
> Please re-read what I said. State your case and the list (and as a
> member that includes you) will decide the appropriateness and usefulness
> of your proposal. But all the selling of how great you are, how
> successful you are or how smart you are will not add anything to the
> decision. It will be on its merits only. And be honest; now a days it is
> too easy to figure out the charlatans. This wisdom comes from someone
> that has been around for 30 years on the "network" and worked on many
> standards and has been involved in the open source community before the FSF.
>
> C.
>
>
>
> Jason N. Meiers wrote:
> > As far as I understand this is a democracy, I can particiapte in the
> > evaluation.
>
> > On Mon, Mar 9, 2009 at 2:57 PM, <eprparad...@gmail.com
> > <mailto:eprparad...@gmail.com>> wrote:
>
> > Jason,
>
> > Just make your case for your "solution" and leave it to the list to
> > determine if it has any value. Stop trying to "sell" us on how smart you
> > are, how great you are or how successful you are. We will just evaluate
> > you proposal on how well it does what it is supposed to do and how it
> > stacks up to the other solutions out there.
>
> > C.
>
> > Jason N. Meiers wrote:
> > > @TL
>
> > > the requriements are from building a successful SaaS company
> > tranforming
> > > traditional inhouse hosted software to SaaS on EC2
> > >http://www.camsolutionsinc.com/
>
> > > as well as from experice working in a 24x7 environment as IT
> > > administrator and understanding the challenges including sleepless
> > > nights due to events and alerts.
>
> > > On Mon, Mar 9, 2009 at 2:42 PM, Jason N. Meiers
> > <jason.mei...@gmail.com <mailto:jason.mei...@gmail.com>
> > <mailto:eprparad...@gmail.com>> wrote:
>
> > Jason,
>
> > Just make your case for your "solution" and leave it to the list to
> > determine if it has any value. Stop trying to "sell" us on how smart you
> > are, how great you are or how successful you are. We will just evaluate
> > you proposal on how well it does what it is supposed to do and how it
> > stacks up to the other solutions out there.
>
> > C.
>
> > Jason N. Meiers wrote:
> > > @TL
>
> > > the requriements are from building a successful SaaS company
> > tranforming
> > > traditional inhouse hosted software to SaaS on EC2
> > >http://www.camsolutionsinc.com/
>
> > > as well as from experice working in a 24x7 environment as IT
> > > administrator and understanding the challenges including sleepless
> > > nights due to events and alerts.
>
> > > On Mon, Mar 9, 2009 at 2:42 PM, Jason N. Meiers
> > > <mailto:jason.mei...@gmail.com <mailto:jason.mei...@gmail.com>>>
> > wrote:
>
> > > yes there are alot of stuff of the shelf with XMPP just for IT
> > > administrators to difficult to implement and manage change
> > compared
> > > to other protocols. xmpp is like c++ where semp would be a
> > ruby. To
> > > manage changing IT environments .
>
> > > On Mon, Mar 9, 2009 at 2:38 PM, Egon Willighagen
> > > <egon.willigha...@gmail.com
>
> > > yes there are alot of stuff of the shelf with XMPP just for IT
> > > administrators to difficult to implement and manage change
> > compared
> > > to other protocols. xmpp is like c++ where semp would be a
> > ruby. To
> > > manage changing IT environments .
>
> > > On Mon, Mar 9, 2009 at 2:38 PM, Egon Willighagen
> > <mailto:egon.willigha...@gmail.com>
> > <mailto:egon.willigha...@gmail.com
> > <mailto:egon.willigha...@gmail.com>>> wrote:
>
> > > On Mon, Mar 9, 2009 at 2:35 PM, JM <jason.mei...@gmail.com
> > <mailto:jason.mei...@gmail.com>
> > > <mailto:jason.mei...@gmail.com
> > <mailto:jason.mei...@gmail.com>>> wrote:
> > > > nice, this is specialized for geographical data to tell
> > you where
> > > > soemthing is located on the planet. sweet.
>
> > > > althought its not cloud event management. the strong accent
> > > for lat
> > > > and long rather than severity, status or other event
> > managenet
> > > related
> > > > figures.
>
> > > This is something I like about XMPP, there is a solution
> > to a lot of
> > > things of the shelf. Glad to see you like it.
>
> > > Egon
>
> > > --
> > > Post-doc @ Uppsala University
> > > http://chem-bla-ics.blogspot.com/- Hide quoted text -
> > > > nice, this is specialized for geographical data to tell
> > you where
> > > > soemthing is located on the planet. sweet.
>
> > > > althought its not cloud event management. the strong accent
> > > for lat
> > > > and long rather than severity, status or other event
> > managenet
> > > related
> > > > figures.
>
> > > This is something I like about XMPP, there is a solution
> > to a lot of
> > > things of the shelf. Glad to see you like it.
>
> > > Egon
>
> > > --
> > > Post-doc @ Uppsala University
>
> - Show quoted text -
Peter Saint-Andre
Mar 9, 2009, 10:17:44 AM3/9/09
to cloud...@googlegroups.com
On 3/8/09 1:37 AM, Jason N. Meiers wrote:
> @Jayson
>
> The proxy for consolidating ACL change requersst is nessesary and an
> extension that will benefit SEMP. That being said, SEMP changes are
> built based on requirements for Cloud Computing specifically not Jabber
> or other non-cloud computing specific requirments.
> @Jayson
>
> The proxy for consolidating ACL change requersst is nessesary and an
> extension that will benefit SEMP. That being said, SEMP changes are
> built based on requirements for Cloud Computing specifically not Jabber
> or other non-cloud computing specific requirments.
XMPP is basically just a way to get small bits of XML from one place to
another -- an XML router, if you will. What you build on top of that is
up to you -- instant messaging, presence, geolocation, middleware,
multimedia negotiation, you name it. So if people who are interested in
cloud computing want to define some XMPP extensions, they are free to do
so inside or outside the XMPP Standards Foundation.
> Major benefits for using SEMP opposed to SNMP or XMPP
>
> - Simple
> - Fixed parameters ( Vendors cater to IT Administrators not the other
> way around i.e SNMP or JMX , XMPP )
> - Protocol implementation changes are dictated by cloud requriments not
> Google, Jabber or for other multipurpose applications.
See above.
> The only major benefit for XMPP is that larger companies are pushing it.
>
> - Google
> - Jabber
Having worked at Jabber Inc. since 1999 through its recent acquisition
by Cisco, I can tell you that calling Jabber Inc. a larger company is
laughable. Unless you mean that a company with 55 employees is larger.
Peter Saint-Andre
Mar 9, 2009, 10:30:02 AM3/9/09
to cloud...@googlegroups.com
On 3/8/09 4:05 AM, Jason N. Meiers wrote:
> With these vendors financing XMPP there is no intent to improve the
> quality for IT administrators your service but rather thier devices.
Baseless accusations such as these deserve a response.
> XMPP Sponsors
These are not sponsors of XMPP, they are sponsors of the XMPP Standards
Foundation. Two very different things.
> AG Software <http://xmpp.org/xsf/sponsors/agsoftware.shtml>
> Cleartext <http://xmpp.org/xsf/sponsors/cleartext.shtml>
> DreamHost <http://xmpp.org/xsf/sponsors/dreamhost.shtml>
> Google <http://xmpp.org/xsf/sponsors/google.shtml>
> HP <http://xmpp.org/xsf/sponsors/hp.shtml>
> Jabber Inc. <http://xmpp.org/xsf/sponsors/jabberinc.shtml>
> Jive Software <http://xmpp.org/xsf/sponsors/jivesoftware.shtml>
> Process-one <http://xmpp.org/xsf/sponsors/process-one.shtml>
> USSHC <http://xmpp.org/xsf/sponsors/usshc.shtml>
> Wimba <http://xmpp.org/xsf/sponsors/wimba.shtml>
Since when are AG Software, Cleartext, DreamHost, Process-one, USSHC,
and Wimba large companies or even device manufacturers? (In fact they
are small software developers and hosting companies.) HP is primarily a
user of XMPP technologies (they use it internally for their IM and
presence functionality). Google is not a device manufactuer, whatever
else you might say about them. And Jabber Inc. has been a small software
development company since March 2000 (until being purchased by Cisco in
October 2008).
XMPP is an open technology originally developed in an open-source
community, formalized via the IETF's open standards process,
continuously extended by the XMPP Standards Foundation (an independent,
not-for-profit, 501(c)3 organization in which anyone can participate,
not just people who "pay to play"), and implemented in dozens of
open-source codebases. The fact that larger companies have just started
to become interested in XMPP technologies after 10 years of development
out in the open does not mean that any particular company is trying to
push XMPP to sell hardware. It is far, far too late for any one company
to try to control XMPP, because the technology has been open for more
than ten years now.
I could go on, but I've already spent far too much time debunking your
uninformed ravings and conspiracy theories. I won't post again in this
thread.
Jason N. Meiers
Mar 9, 2009, 10:32:32 AM3/9/09
to cloud...@googlegroups.com
Cisco has an interesting concept of XMPP althought Can't wait for Juniper Networks to publish thier protocol. Who knows it maybe specifically for clouds. It surly wont be XMPP due to the (X) which is too stuffy for clouds.
Jason N. Meiers
Mar 9, 2009, 10:33:37 AM3/9/09
to cloud...@googlegroups.com
Cisco supports a protocol for free right. And first priority the IT admin. Keep drinnking the cool-aid.
Jason N. Meiers
Mar 9, 2009, 12:09:02 PM3/9/09
to cloud...@googlegroups.com
Sam, TL has valid critic sometimes. You don't. The question I have for you is what is your mission at CCIF? Are your for interop or not? How do you contribute? What technical benefits do you see for XMPP and SEMP?
On Mon, Mar 9, 2009 at 4:48 PM, Sam Johnston <sa...@samj.net> wrote:
Pat,The inappropriateness of your comment (as Reuven/Enomaly's employee) aside, there is no SEMP mailing list that I am aware of - and no SEMP so far as we can tell (the Google Code project remains empty). Aside from the various personal attacks from one vendor, the other contributors to this thread (including TL and myself) have raised pertinent points about a proposed standard as well as relevant technical details about a major component - both of which are clearly on topic.I agree. TL/Sam/Jason, please take your discussion of SEMP to the SEMP mailing list. Real time communication tools are a really great for building cloud systems, but I'm not sure we should get this hung up on the specifics yet.
If, as you say, we should "[not] get this hung up on the specifics yet" then when would you say is a good time, bearing in mind that the group has been around for six months already and others (e.g. here and here) are popping up every day to address its charter?
Sam
Sam Johnston
Mar 9, 2009, 1:05:48 PM3/9/09
to cloudforum
On Mon, Mar 9, 2009 at 5:09 PM, Jason N. Meiers <jason....@gmail.com> wrote:
I think I speak for most of us here when I say that our concern is for the timely development of useful, open cloud standards, irrespective of the source or branding. I also don't need to justify myself to you any more than an AC poster does but if you want another example then check out my Cloud User SHell cush (which could easily become a harness for e.g. an EC2 toolchain replacement).Sam, TL has valid critic sometimes. You don't. The question I have for you is what is your mission at CCIF? Are your for interop or not? How do you contribute? What technical benefits do you see for XMPP and SEMP?
Since you asked (and keeping this thread focused on the topic rather than the individuals), the 'X' in 'XMPP' stands for 'Extensible'. This gives some indication of how important extensibility is to the protocol and as was explained to you previously, other protocols like SNMP would not have been as successful today were it not for the ability to break away from the base feature set. In short, many of us see a "canned set of variables" to be a limitation rather than a feature - something present in ancient standards but eliminated almost entirely from recent ones. In any case this 'enum' functionality can be trivially implemented on top of XMPP, while the revere cannot be said of SEMP (that is, if SEMP does not have the features you need then you're hosed).
It is also pertinent that the protocol itself is rarely of concern to developers and almost never of concern to system administrators (once it has been written into a client library). I've written XMPP various applications and was up and running with a Google Talk bot in no time when I first started. I could have written it in any one of a myriad different languages but the same cannot be said for a protocol lacking a range of compliant implementations.
Anyway, the application of XMPP in cloud computing environments (outside of Apple's MobileMe service which I reverse engineered last year) still only really exists in theory and labs. There are certainly some interesting use cases where it could fit but that's not to say it's "magic fairy dust" - if anything that's REST over HTTP[S]. For these use cases XMPP seems a pretty good fit and it's going to take more than idealogical differences to change that - e.g. wide support, no patent problems, various implementations, proven scalability, etc.
I'd suggest avoiding any further discussion about SEMP without a lot more detail about what it is, any intellectual property protection (e.g. patents) that apply, a number of interoperable implementations and perhaps most importantly, a solid explananation about why it is sufficiently compelling as to displace the incumbent.
Sam
eprpa...@gmail.com
Mar 9, 2009, 1:51:04 PM3/9/09
to cloud...@googlegroups.com
I don't even know why XMPP would be the greatest solution for connecting
to various nodes in the cloud. It is only one approach and has some down
sides.
Personally I think the approach needed now is to focus on what the cloud
is and what is needed to make it all work without regard to
implementation. Without a clear picture of features and benefits to the
customer we will never have a cloud business.
Chuck Wegrzyn
Sam Johnston wrote:
> On Mon, Mar 9, 2009 at 5:09 PM, Jason N. Meiers <jason....@gmail.com
> <mailto:jason....@gmail.com>> wrote:
>
> Sam, TL has valid critic sometimes. You don't. The question I have
> for you is what is your mission at CCIF? Are your for interop or
> not? How do you contribute? What technical benefits do you see for
> XMPP and SEMP?
>
>
> I think I speak for most of us here when I say that our concern is for
> the timely development of useful, open cloud standards, irrespective of
> the source or branding. I also don't need to justify myself to you any
> more than an AC poster does but if you want another example then check
> out my Cloud User SHell cush <http://code.google.com/p/cush/> (which
to various nodes in the cloud. It is only one approach and has some down
sides.
Personally I think the approach needed now is to focus on what the cloud
is and what is needed to make it all work without regard to
implementation. Without a clear picture of features and benefits to the
customer we will never have a cloud business.
Chuck Wegrzyn
Sam Johnston wrote:
> On Mon, Mar 9, 2009 at 5:09 PM, Jason N. Meiers <jason....@gmail.com
> <mailto:jason....@gmail.com>> wrote:
>
> Sam, TL has valid critic sometimes. You don't. The question I have
> for you is what is your mission at CCIF? Are your for interop or
> not? How do you contribute? What technical benefits do you see for
> XMPP and SEMP?
>
>
> I think I speak for most of us here when I say that our concern is for
> the timely development of useful, open cloud standards, irrespective of
> the source or branding. I also don't need to justify myself to you any
> more than an AC poster does but if you want another example then check
> could easily become a harness for e.g. an EC2 toolchain replacement).
>
> Since you asked (and keeping this thread focused on the topic rather
> than the individuals), the 'X' in 'XMPP' stands for 'Extensible'. This
> gives some indication of how important extensibility is to the protocol
> and as was explained to you previously, other protocols like SNMP would
> not have been as successful today were it not for the ability to break
> away from the base feature set. In short, many of us see a "canned set
> of variables" to be a limitation rather than a feature - something
> present in ancient standards but eliminated almost entirely from recent
> ones. In any case this 'enum' functionality can be trivially implemented
> on top of XMPP, while the revere cannot be said of SEMP (that is, if
> SEMP does not have the features you need then you're hosed).
>
> It is also pertinent that the protocol itself is rarely of concern to
> developers and almost never of concern to system administrators (once it
> has been written into a client library). I've written XMPP various
> applications and was up and running with a Google Talk bot in no time
> when I first started. I could have written it in any one of a myriad
> different languages but the same cannot be said for a protocol lacking a
> range of compliant implementations.
>
> Anyway, the application of XMPP in cloud computing environments (outside
> of Apple's MobileMe service which I reverse engineered last year
> <http://samj.net/2008/07/apple-iphone-20-real-story-behind-push.html>)
>
> Since you asked (and keeping this thread focused on the topic rather
> than the individuals), the 'X' in 'XMPP' stands for 'Extensible'. This
> gives some indication of how important extensibility is to the protocol
> and as was explained to you previously, other protocols like SNMP would
> not have been as successful today were it not for the ability to break
> away from the base feature set. In short, many of us see a "canned set
> of variables" to be a limitation rather than a feature - something
> present in ancient standards but eliminated almost entirely from recent
> ones. In any case this 'enum' functionality can be trivially implemented
> on top of XMPP, while the revere cannot be said of SEMP (that is, if
> SEMP does not have the features you need then you're hosed).
>
> It is also pertinent that the protocol itself is rarely of concern to
> developers and almost never of concern to system administrators (once it
> has been written into a client library). I've written XMPP various
> applications and was up and running with a Google Talk bot in no time
> when I first started. I could have written it in any one of a myriad
> different languages but the same cannot be said for a protocol lacking a
> range of compliant implementations.
>
> Anyway, the application of XMPP in cloud computing environments (outside
> of Apple's MobileMe service which I reverse engineered last year
tluk...@exnihilum.com
Mar 9, 2009, 1:51:34 PM3/9/09
to cloud...@googlegroups.com
Jason N. Meiers wrote:
>> "..I can particiapte in the evaluation."
Hey, we could ALL participate in the evaluation if you would just produce some actual code and documentation to evaluate! Why in the world you would send us all to an empty Google code site in the first place is really beyond me.
TL
-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/09/2009 09:59 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy
..
>> "..I can particiapte in the evaluation."
Hey, we could ALL participate in the evaluation if you would just produce some actual code and documentation to evaluate! Why in the world you would send us all to an empty Google code site in the first place is really beyond me.
TL
-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/09/2009 09:59 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy
As far as I understand this is a democracy, I can particiapte in the evaluation.
....
Reply all
Reply to author
Forward
0 new messages