On tor, 2004-06-17 at 16:48 -0400, Rachel Blackman wrote:
Hi,
While I agree that Jabber is a bit too technical for the avarage end
user (like current MSN/ICQ/IChat users) I don't agree that the problem
is on the client side (which I kinda got the feeling that you where
targeting with this
On Sun, 4 Jul 2004 22:14, Mikael Hallendal wrote:
Being the author of a jabber client (Gossip) targeting this audience my
biggest concerns are the lack of standard on how a server is
configured. You can never count on for example group chat to be
available on the server the user happens to
On Fri, 18 Jun 2004 08:53, Rachel Blackman wrote:
If you write it as a hobby, though, do you necessarily need the banner
on your page? To put it another way, not every webpage author is going
to strive for absolute W3C HTML4 compliance, but if you achieve it and
get it verified by one of
On Thursday 17 June 2004 5:44 pm, Thomas Muldowney wrote:
The DTCP argument is old and dead. It was a matter of multiple
standards doing the same job coming out at the same time and then
people pushing and shoving to make something move to the head of the
class. That issue is over and dead,
Hello,
It all makes sense to me ... I think it is a great idea.
Michael
On Thu, 17 Jun 2004 20:04:27 -0400
Rachel Blackman [EMAIL PROTECTED] wrote:
And Tkabber _still_ does DTCP based File Transfer instead of
Bytestreams. Yay
for standards.
Then Tkabber fails its
Rachel was suggesting that the certification program might want to
recommend
experimental JEPs, and I'm just trying to explain that this is a bad
idea.
Again, even if this has been the mindset in the past, it's not
necessarily such now.
I can't imagine the JSF have a certification program
Greetings,
I would offer one thought about this Should I implement Experimental JEPs
question that seems to be arising from the discussion about certification.
The original point of the JEP was that it was an extension PROPOSAL and as
such, it was assumed that whomever was making the proposal
On Jun 18, 2004, at 5:21 AM, Justin Karneges wrote:
I may have had a cynical tone in my post, but I wasn't rehashing an
argument.
Standards, procedures, and policies are important. Maybe I wasn't
happy with
what happened back then, but if you re-read my text above you'll see
that I'm
actually
I believe that the reason that client developers do not implement these
particular JEP's is because there may be no demand for them at this time in
their XMPP applications, not just because they are marked as 'experimental'.
There are JEP's that have some value to me (pubsub, sasl, geoloc, CAP,
On Thu, 17 Jun 2004 20:04:27 -0400, Rachel Blackman
[EMAIL PROTECTED] wrote:
I shouldn't really define certification as something you 'lose'; it'd be
something you have to strive to /gain/ each year.
Ofcourse that sounds fair enough!
Let me quote you on what started this thread:
The thing is,
Ms. Blackman is not advocating certification for its own sake. The
piece that I think was left unsaid was that there's all these cool specs
for features, and users have a real desire to have those features, yet
client haven't implemented them.
As a case in point, I refer to a fairly-recent
The thing is, there are all these very cool Jabber featuresets out
there, but lots of them are not necessarily supported. Nor (other
than peer pressure) is there much incentive for people to implement
certain things. I can look at Jabber and go 'wow, pubsub is a cool
backend system, Stream
Ms. Blackman is not advocating certification for its own sake. The
piece that I think was left unsaid was that there's all these cool
specs for features, and users have a real desire to have those
features, yet client haven't implemented them.
As a case in point, I refer to a fairly-recent
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rachel Blackman
Sent: Friday, June 18, 2004 10:33 AM
To: Jabber software development list
Subject: Re: [jdev] Jabber Certification Program
The thing is, there are all these very cool Jabber featuresets out
there, but lots
I don't think you need an entire certification process for this. We could
simply rearrange the client list to indicate which clients support which
features. The client author(s) would need to submit this information. I
don't think mispresentation by the client authors would be an issue. Even
Stephen Pendleton Wrote:
The client author(s) would need to submit this information. I
don't think mispresentation by the client authors would be an
issue.
I believe that misrepresentation would be an issue. This could probably
be dealt with via policies - if a client is misrepresenting an
] On Behalf Of
Chris Mullins
Sent: Friday, June 18, 2004 3:03 PM
To: Jabber software development list
Subject: RE: [jdev] Jabber Certification Program
Stephen Pendleton Wrote:
The client author(s) would need to submit this information. I don't
think mispresentation by the client authors would
On Fri, 18 Jun 2004 13:33:20 -0400, Rachel Blackman
[EMAIL PROTECTED] wrote:
The thing is, there are all these very cool Jabber featuresets out
there, but lots of them are not necessarily supported. Nor (other
than peer pressure) is there much incentive for people to implement
certain things.
This point is absolutly valid. Though there still seems to be
confusion on what excactly is proposed. Eg. certification on features
vs. profiles (your reply to Matthew Millar seems to conflict with the
earlier idea of profiles such as minimal, intermidiate, extended).
How deep would
So, Jabber has been around for a while now. It's a great architecture,
we've all drunk the Kool-Aid as it were... but I've recently found a
lot of frustration in one area, and I know from discussion in the jdev
chatroom that I am far from the only one.
The thing is, there are all these very
I wish I had more to say... but all I can think of is: sounds good.
I think it would be a very very good idea to have *one person* be
responsible for the client requirements for a particular year. A
Client Compliance Master 2005 or something... and eventually we could
have a Server Compliance
I think it would be a very very good idea to have *one person* be
responsible for the client requirements for a particular year. A
Client Compliance Master 2005 or something... and eventually we
could have a Server Compliance Master 2006. That person has final
say on what the requirements are,
On 17 Jun 2004, at 17:28, Rachel Blackman wrote:
I think it would be a very very good idea to have *one person* be
responsible for the client requirements for a particular year. A
Client Compliance Master 2005 or something... and eventually we
could have a Server Compliance Master 2006. That
Yes, there is definitely a problem, but I don't I agree with your solution.
Clients are behind because nearly all of them are hobby projects. I think I
can speak for most of us in saying that we are working as fast as we can
within our available time, and throwing a certification weight on our
this is going to be unpopular, but it may be wise to consider such a
fee-based compliance testing process.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Rachel Blackman
Sent: Thursday, June 17, 2004 4:48 PM
To: [EMAIL PROTECTED]
Subject: [jdev] Jabber
On 17 Jun 2004, at 17:48, Justin Karneges wrote:
In addition, many of the features you mention just plain aren't ready
in
specification form. Avatars? XHTML-IM? Voice chat? These are all
Experimental. Maybe we should start certifying Jabber Council
members, to
motivate them to approve some
On Thu, 17 Jun 2004 18:25:34 -0400, Julian Missig [EMAIL PROTECTED]
wrote:
On 17 Jun 2004, at 17:48, Justin Karneges wrote:
How many test implementations of jep-secure are there?
Julian
I think the problem referred to is the fact that it's not even published
on the site yet. Or am I mistaken?
Clients are behind because nearly all of them are hobby projects. I
think I
can speak for most of us in saying that we are working as fast as we
can
within our available time, and throwing a certification weight on our
shoulders wouldn't speed anything up.
If you write it as a hobby, though, do
On Thursday 17 June 2004 3:25 pm, Julian Missig wrote:
Protocols do not move forward by sheer will of the council. The
/reason/ those JEPs are /still/ experimental is because of lack of
implementation attempts.
Do we really want to relive the DTCP disaster again? Ever since that
backlash,
JEPs do not move forward by sheer will of Council or JEP authors.
Client-based JEPs need client implementations to test them and work
out
bugs... and then the Council can start moving things forward based on
real experience.
Has the Council opinion changed? If so, I wasn't aware of it. Real
On Thu, 17 Jun 2004 19:16:07 -0400, Rachel Blackman
[EMAIL PROTECTED] wrote:
And Tkabber _still_ does DTCP based File Transfer instead of
Bytestreams. Yay
for standards.
Then Tkabber fails its compliance and certification test. Which is fine
if they don't care, but they lose the little
And Tkabber _still_ does DTCP based File Transfer instead of
Bytestreams. Yay
for standards.
Then Tkabber fails its compliance and certification test. Which is
fine if they don't care, but they lose the little badge and get
bumped from the list of certified clients; the clients on the list
On Jun 17, 2004, at 6:04 PM, Justin Karneges wrote:
On Thursday 17 June 2004 3:25 pm, Julian Missig wrote:
Protocols do not move forward by sheer will of the council. The
/reason/ those JEPs are /still/ experimental is because of lack of
implementation attempts.
Do we really want to relive the
33 matches
Mail list logo
