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,
Interesting, but why not use the existing jabber:client namespace?
Ralphm
___
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
hai
I have installed gnu pth 2.0 in red hat linux. i have also installed jabber(1.4.3) and
it was completed successfully. But when i tried to start jabber server (
./jabberd/jabberd command)it gives me an error saying
error while loading shared libraries:libpth.so.20: cannot load
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
put the button up for bragging rights.
As you outlined in your original posting, Rachel, part of the
motivation for the certification program would be to help average users
choose the appropriate client. I, personally, would even consider that
the _key_ reason for this kind of certification.
Hey all,
I 100% agree that a certification process would help drive adoption of
JEP's. The long JEP list is simply way too daunting for new client
authors at the moment, and knowing which JEP's are blessed by the
community would help those authors greatly, and would encourage them to
do the extra
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
[Tkabber as an example]
Stop bashing Aleksey's client already, will ya. ;-D
a 'recommended' feature might end up being a 'required' feature the
next year
I wonder: will there be any way to include _customer_ expectations in
the decisions of what will be listed in the certification feature
anecdotal-evidenceWhen talking to users of non-Jabber IM systems,
what I usually hear is that Jabber is too geeky, initial configuration
(including the concept of having to find a server) is too difficult,
etc. In other words, it just does not target the same user audience as
IM services like
1) Encourage standardization and interoperability
2) Indicate (through 'recommended' features in each year's
certification definition) features which are not yet required for
certification but which will likely be required in the following year.
(Including experimental JEPs.)
Hmmm, wouldn't it be
The recommended features are for the client developers, not the end
users. The end users would see all these clients have the features of
a basic Jabber client ... and we may provide a list of extra
features particular clients have.
My point is that we do have the kind of featureset list
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
Well if it is an issue then I think we can realistically say that it would
be resolved by sending the maintainer of the feature list a note. The list
maintainer should be king (or queen) and decide if the feature should be
taken off the clients supported feature list.
I think we need a
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
23 matches
Mail list logo
