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 t
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 proposa
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 t
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 certificat
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.
] 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 cli
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
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
this
ave a certification process in place.
Regards,
Matt
> -Original Message-
> 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 Certific
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 thr
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 In
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 thr
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
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,
JEP
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
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 w
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 invol
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
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 dea
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 DTCP
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
im
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 b
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
expe
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,
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, d
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
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 J
idized the process as
well.
I know 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: [EMAI
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 ou
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
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 a
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
XHTML-IM has been a JEP for a rather long time, and few clients
implement it (and moreover, some of them implement it in a nonstandard
and wacky way!), and it's a fairly basic feature many IM end users
look for. And there's no real incentive (other than peer pressure, as
I said) for a client a
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 co
34 matches
Mail list logo