Re: [Standards] Introduction of Coyo

[Coyo Carami]

huh? o.O

On Fri, Aug 26, 2011 at 1:23 AM,  wrote:

> I am out of office right now and will get back to you when I return. If you
> don't hear from me, my assistant should contact you shortly. In the
> meantime, check this deal on the laptop I just bought for my business
> trips..Click 
> Here
>
> Enable images or click 
> here
> 
> Let me know what you think after you have a chance to review.
> Cheers!
>
> If you no longer wish to receive emails, please 
> unsubscribe
>
> 866-288-1880
> 5150 yarmouth ave, Encino, CA 91316
>
> On Fri, 26 Aug 2011 01:23:04 -0500, Coyo Carami ** wrote:
> Hello all, my name is coyo, and i'm a fan of xmpp.
>
> i intend to also become a developer as a hobby of mine.
>
> i am working on several projects as bug triage and beta testing. a gopher,
> so the speak.
>
> i'm young in the ways of the force, only an egg compared to you mighty
> graybeards, but i'm willing to learn.
>
> i hope i can make some friends here. :3
>
> --
> i am coyotama, and coyotama approves this message :3
>



-- 
i am coyotama, and coyotama approves this message :3

[Standards] Introduction of Coyo

[Coyo Carami]

Hello all, my name is coyo, and i'm a fan of xmpp.

i intend to also become a developer as a hobby of mine.

i am working on several projects as bug triage and beta testing. a gopher,
so the speak.

i'm young in the ways of the force, only an egg compared to you mighty
graybeards, but i'm willing to learn.

i hope i can make some friends here. :3

-- 
i am coyotama, and coyotama approves this message :3

Re: [Standards] Microblogging: XEP-0277 and beyond

[Justin Karneges]

On Thursday, August 25, 2011 07:27:16 AM Sergey Dobrov wrote:
> On 08/25/2011 03:36 AM, Justin Karneges wrote:
> > Yes, if tracking changes is needed then the node should have a way of
> > offering items ordered by modified time.
> > 
> > Being able to query for items using different kinds of orderings would be
> > useful though, so I didn't want to stipulate that pubsub with RSM must
> > always be ordered by modified time.  Rather, each node would have some
> > sort of natural ordering depending on intended purpose, and if we want
> > the client to be able to select among multiple orderings offered by a
> > node then that would be a separate extension or scheme.
> 
> Yes, it's sounds ok but what with retracts again?

At the moment, I feel this is best done by having a node-specific item format 
indicating deletion.  For Atom-based pubsub nodes, this could be contentless 
.

But I think it would also be good to see about getting  into the spec 
for iq exchange.

> And how I can
> understand if I missed something and should to re-request items from node?

Each pubsub message event should contain two RSM ids: the id of the item 
contained in the event as well as the id of the item that directly precedes it 
according to the item ordering.  Whether by iq or message, the client would 
remember the last known RSM id.  If a message event is received and the "id of 
preceding item" in that message does not match the last id known by the 
client, then the client can choose to catch up by using iq to fetch items 
since the last known id.

We could use SHIM for this:

  http://jabber.org/protocol/shim";>
64fc10d2
f4ac5920
  

> > For example, my XEP-0303 proposes selecting ordering using special node
> > name suffixing, such as "?order=-created" to indicate created time
> > descending order. But this is just one way to go about it.
> 
> I don't have enough time to dive into XEP-303 enough but I don't think
> that this is a good idea to use "dynamic" pubsub nodes without separate
> XEP for it. Again, I don't think that different ordering is really need
> at this time.

Maybe you don't need it, but I need it. :)  The commenting protocol requires 
both created time ordering (for application display render) and modified time 
ordering (for tracking updates).  But, I am open to discussing alternatives 
that don't involve dynamic node names.

Justin

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

[Matthew A. Miller]

On Aug 25, 2011, at 07:46, Ralph Meijer wrote:

> On Thu, 2011-08-25 at 15:00 +0200, Andreas Monitzer wrote:
>> On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote:
>>> Right, there are use cases (e.g., vCards in chatrooms) that make PEP
>>> unworkable. I'm willing to have the discussion again. :)
>> 
>> Then why not fix it at the source (PEP), maybe by creating a separate
>> XEP for MUC-PEP? Is it better to have a workaround in every XEP that
>> would otherwise use PEP instead?
> 
> Agreed. We've talked about his on several instances of the XMPP Summit,
> lastly in the Cisco offices near Brussels, sparked by the very same
> specification for vCard.
> 
> As far as I can remember we covered a lot of ground, but didn't reach a
> conclusion. I'm not sure if anyone made notes there, but it would be
> valuable to have a summary of aspects and issues around PubSub inside
> MUC. Kevin, Matt, Joe, do you have such notes?
> 

I have some notes from a e2e discussion, but they only say "MUC should support 
PEP" (-:

> 
>> My major issue is that requiring specific server support results in a
>> huge delay in deployment, and some servers will never support it at
>> all (which means that client developers will still have to implement
>> vcard-temp in 2020), since many server developers and admins are of
>> the kind "if it ain't broke, don't touch it".
> 
> I'm not sure if this is also about using PEP for transporting vCard4,
> but I seem to remember some of the possible solutions did impose
> cooperation of the MUC room for doing PEP 'properly'.
> 

Agreed.


- m&m

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

[Peter Saint-Andre]

On 8/25/11 7:46 AM, Ralph Meijer wrote:
> On Thu, 2011-08-25 at 15:00 +0200, Andreas Monitzer wrote:
>> On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote:
>>> Right, there are use cases (e.g., vCards in chatrooms) that make PEP
>>> unworkable. I'm willing to have the discussion again. :)
>>
>> Then why not fix it at the source (PEP), maybe by creating a separate
>> XEP for MUC-PEP? Is it better to have a workaround in every XEP that
>> would otherwise use PEP instead?
> 
> Agreed. We've talked about his on several instances of the XMPP Summit,
> lastly in the Cisco offices near Brussels, sparked by the very same
> specification for vCard.
> 
> As far as I can remember we covered a lot of ground, but didn't reach a
> conclusion. I'm not sure if anyone made notes there, but it would be
> valuable to have a summary of aspects and issues around PubSub inside
> MUC. Kevin, Matt, Joe, do you have such notes?

I don't know of any such notes.

>> My major issue is that requiring specific server support results in a
>> huge delay in deployment, and some servers will never support it at
>> all (which means that client developers will still have to implement
>> vcard-temp in 2020), since many server developers and admins are of
>> the kind "if it ain't broke, don't touch it".
> 
> I'm not sure if this is also about using PEP for transporting vCard4,
> but I seem to remember some of the possible solutions did impose
> cooperation of the MUC room for doing PEP 'properly'.

That is my recollection, too.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] Microblogging: XEP-0277 and beyond

[Sergey Dobrov]

On 08/25/2011 03:36 AM, Justin Karneges wrote:
> On Wednesday, August 24, 2011 03:34:27 AM Sergey Dobrov wrote:
>> On 08/24/2011 01:38 AM, Justin Karneges wrote:
>>> On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote:
 On 08/23/2011 09:14 AM, Justin Karneges wrote:
> The basic solve for item retraction is for the server to keep deletion
> markers around.  For example the server could clear all content of an
> item and flag it as deleted, but keep it in the same position in the
> item list.  This way retracted items can be reported in iq responses.

 That would not work because it is equal to the item update with the
 blank payload but how could you know that the item was updated?
>>>
>>> I'm still unsure what you're saying but I'll try to guess: do you mean to
>>> say that you cannot determine the difference between a publish vs
>>> update, unless you have a local copy of the item to compare with?  If
>>> so, I have found that in many situations this does not actually matter. 
>>> Can you share a use case?
>>
>> No, I tell you that even if I will be able to receive items according to
>> the publish time then I can't find if some items was updated before that
>> time. But if it's by modify time then yes, all seems to be ok except of
>> retract.
> 
> Yes, if tracking changes is needed then the node should have a way of 
> offering 
> items ordered by modified time.
> 
> Being able to query for items using different kinds of orderings would be 
> useful though, so I didn't want to stipulate that pubsub with RSM must always 
> be ordered by modified time.  Rather, each node would have some sort of 
> natural 
> ordering depending on intended purpose, and if we want the client to be able 
> to select among multiple orderings offered by a node then that would be a 
> separate extension or scheme.
Yes, it's sounds ok but what with retracts again? And how I can
understand if I missed something and should to re-request items from node?

> 
> For example, my XEP-0303 proposes selecting ordering using special node name 
> suffixing, such as "?order=-created" to indicate created time descending 
> order.  
> But this is just one way to go about it.
I don't have enough time to dive into XEP-303 enough but I don't think
that this is a good idea to use "dynamic" pubsub nodes without separate
XEP for it. Again, I don't think that different ordering is really need
at this time.

> 
> Justin
> 


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

[Ralph Meijer]

On Thu, 2011-08-25 at 15:00 +0200, Andreas Monitzer wrote:
> On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote:
> > Right, there are use cases (e.g., vCards in chatrooms) that make PEP
> > unworkable. I'm willing to have the discussion again. :)
> 
> Then why not fix it at the source (PEP), maybe by creating a separate
> XEP for MUC-PEP? Is it better to have a workaround in every XEP that
> would otherwise use PEP instead?

Agreed. We've talked about his on several instances of the XMPP Summit,
lastly in the Cisco offices near Brussels, sparked by the very same
specification for vCard.

As far as I can remember we covered a lot of ground, but didn't reach a
conclusion. I'm not sure if anyone made notes there, but it would be
valuable to have a summary of aspects and issues around PubSub inside
MUC. Kevin, Matt, Joe, do you have such notes?


> My major issue is that requiring specific server support results in a
> huge delay in deployment, and some servers will never support it at
> all (which means that client developers will still have to implement
> vcard-temp in 2020), since many server developers and admins are of
> the kind "if it ain't broke, don't touch it".

I'm not sure if this is also about using PEP for transporting vCard4,
but I seem to remember some of the possible solutions did impose
cooperation of the MUC room for doing PEP 'properly'.

--
ralphm

Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

[Andreas Monitzer]

On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote:
> Right, there are use cases (e.g., vCards in chatrooms) that make PEP
> unworkable. I'm willing to have the discussion again. :)

Then why not fix it at the source (PEP), maybe by creating a separate XEP for 
MUC-PEP? Is it better to have a workaround in every XEP that would otherwise 
use PEP instead?

My major issue is that requiring specific server support results in a huge 
delay in deployment, and some servers will never support it at all (which means 
that client developers will still have to implement vcard-temp in 2020), since 
many server developers and admins are of the kind "if it ain't broke, don't 
touch it".

Regards,
Andreas Monitzer

Re: [Standards] Microblogging: XEP-0277 and beyond

[Ralph Meijer]

On Tue, 2011-08-23 at 08:34 -0600, Joe Hildebrand wrote:
> On 8/21/11 4:45 PM, "Justin Karneges"
>  wrote:
> 
> > Good catch, I didn't consider clock skew.  I wonder if the client should 
> > just
> > specify a timestamp 5-10m in the past instead of having magic at the node
> > servers.  Then accurate time queries (made relative to timestamps of other
> > items provided by the server) stay optimized.
> 
> Seems to me that client writers are more likely to incorrectly think the
> server clock is going to be "right" than the other way around, but I don't
> care where the skew is added as long as it's specified which side does it,
> so we don't double-skew.

I'm wonder how good this would work in practice. Distributed clocks are
hard. I am also not sure if you would actually need/want this in
practice. Thinking aloud from here on.

The use of information like User Mood and User Tune in IM clients is
usually that they are just shown as icons in a roster. However, I image
that most 'microblogging' applications would have a 'river of updates'
UI. In this setting, I'd assume you want to limit the updates in some
way (more specific types, more specific senders (not everyone on your
roster), etc). Would you then still use implicit subscriptions?

If not, I assume the subscription would persist over sessions, only
sending out notifications based on presence. Now you need a way to
exchange your client's state to each of the services that you hold
subscriptions with. These RSM ids would work, but it is a cumbersome to
send these out every time you come online. The only thing I could come
up with is a twisted scheme were you basically do acking on received
notifications. I.e. the service remembers what you got last.

Hmm.

--
ralphm

Re: [Standards] Microblogging: XEP-0277 and beyond

[Ralph Meijer]

On Wed, 2011-08-24 at 17:34 +0700, Sergey Dobrov wrote:
> On 08/24/2011 01:38 AM, Justin Karneges wrote:
> > On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote:
> >> On 08/23/2011 09:14 AM, Justin Karneges wrote:
> >>> The basic solve for item retraction is for the server to keep deletion
> >>> markers around.  For example the server could clear all content of an
> >>> item and flag it as deleted, but keep it in the same position in the
> >>> item list.  This way retracted items can be reported in iq responses.
> >>
> >> That would not work because it is equal to the item update with the
> >> blank payload but how could you know that the item was updated?
> > 
> > I'm still unsure what you're saying but I'll try to guess: do you mean to 
> > say 
> > that you cannot determine the difference between a publish vs update, 
> > unless 
> > you have a local copy of the item to compare with?  If so, I have found 
> > that 
> > in many situations this does not actually matter.  Can you share a use case?
> No, I tell you that even if I will be able to receive items according to
> the publish time then I can't find if some items was updated before that
> time. But if it's by modify time then yes, all seems to be ok except of
> retract.

Are you saying here that you want intermediate changes for the same item
(i.e. the same ItemID) that took place while the client was not online
to receive the notifications?

If so, the model in XEP-0060 is that each update to an item is a
complete replacement for that item, so a service will not keep record of
previous 'versions'. If you really want that you should probably use
unique identifiers for each update.

In the field of microblogging I don't see a particular use case for
this. Microblog entries typically don't change once posted, and even if
they would, an end-user would probably only be interested in the most
recent version.

For more expanded use cases in Federating Social Networks (beyond
microblogs) that cover other social objects (regular blogs, stories,
pictures, people's profiles) updates are more common. Let me expand on a
real-world example.

At Mediamatic we've built a network of sites that federate using
(amongst others) XMPP PubSub. The sites are basically collections of
Things that have relationships or Edges between them, with a particular
predicate. Very semantic web, RDF-like. For exchanging Things, we make
an Atom representation of the Thing with all of its 'outgoing' Edges,
encoded as  elements. (Example:
http://www.mediamatic.net/atom/24879). Each Thing has its own node
(xmpp:pubsub.mediamatic.net?;node=id/24879).

In this setting, for each update (changed title, new relationships) we
just push the whole representation to the subscribing sites (ItemID
'current'). Upon reception, the local shadow representation is entirely
replaced with the version just received.

We did think about sending around delta's at some point, especially for
edge updates, because the pings are really fat. Up till now, we haven't
pursued this because it makes the operation more fragile. If you missed
an update, you have to figure what you've missed, likely by replaying a
journal.

Alternatively, I could think of having a more explicit subscription,
where you have the publishing service filter out certain bits (unwanted
edges with particular predicates) in the Atom in the notification, and
only send updates for 'fields' you are interested in.

We also played with the thought of having separate items for derived
(meta) data for each thing. These could hold information on the amount
of comments, likes, visits and various 'ratings', that you might want to
show on the federated sites. We haven't pursued this mostly because lack
of time. I'm also not sure about how to encode this information, as
items in a node typically have their payload in the same namespace.
Encoding this meta data in Atom might be somewhat of an overkill.


> >> From my point of view, the best solution is node journal but I can't be
> >> sure since that idea was not discussed.
> > 
> > True.  I am trying to avoid this if possible.  My stance is there is 
> > nothing 
> > wrong with using a journal to implement pubsub, but ideally pubsub-using 
> > protocols should not be so complex that they require a journal-based 
> > implementation to participate.
> I don't insist on journal, I just need a reliable way to retrieve node
> changes and I can't think up another way.

In our case, we don't retract items, but do send node deletes (sometimes
with a redirected to another Thing, when there was a move between sites
or two things have been consolidated into one). I suppose that wouldn't
work nicely in your setting, because all of our subscriptions are
explicit.

We do have something akin to collections or 'generic subscriptions',
which act more like an Atom Feed. There we create or update items based
on the atom:id inside the payloads, and don't actually look at the
ItemID. Deletes are not published in this sett