[Standards-JIG] Roster block importing and synchronisation using JEP-0093

Mike Albon mikea at yuri.org.uk
Wed Sep 15 18:54:04 UTC 2004


Tijl,

Thanks for you comments .However I feel we have reached the point where
we will be going round in circles. So it is probably best to park this
discussion here as I believe it has no further useful purpose.

Regards

Mike

On Wed, 2004-09-15 at 20:13 +0200, Tijl Houtbeckers wrote:
> On Wed, 15 Sep 2004 17:06:32 +0100, Mike Albon <mikea at yuri.org.uk> wrote:
> 
> >> I have 'em in my roster as we speak (Jabberd 1.4). The only way to get
> >> someone out of your roster is a jabber:iq:roster query. XMPP IM also
> >> treats this as normal.
> >
> > I'm not disagreeing with you, I just haven't seen that behaviour. I sat
> > and read my roster file (that was fun I can tell you), but I have no
> > 'none' items in my roster. It maybe because it has remained relatively
> > static for a long time.
> 
> Well, have someone put you on their roster, then remove you, and see what  
> happens. What client are you using? Maybe it hides them.
> 
> 
> >> I think the most important issue is, when I delete a contact on the  
> >> legacy
> >> network, and then use jabber and a transport, I want that contact to be
> >> gone from my list. Whether it's state is "both", "from", "to" or "none",
> >> it won't be online anyway. I just want it out of my list. (Ofcourse for
> >> transports (cause of the probes) "none" is much preferred.)
> >
> > So we were talking cross purposes. You've sort of confused me on your
> > position. Sometimes you mention you wish to have a haunted roster (which
> > ghosts or 'none' items)
> 
> An item is only a "ghost" item as far as I'm concerned when I've already  
> deleted it. For the rest I've called them "none" contacts, and explained  
> they can have a legitemate persons.
> 
> I have items in my roster from contacts I deleted using legacy clients,  
> though probably that is because of different implementation issues, since  
> implementations work differently now. So I'd like to avoid such issues in  
> the future.
> 
> > and yet you are advocating auto-removal of items
> > that have been removed on the legacy roster.
> 
> I've *already* deleted these.
> 
> > What happens when the
> > legacy service has such poor semantics that items just disappear from a
> > roster because thats the way it handles it?
> 
> That would be a specific issue of that legacy network. Do you know any? If  
> there is no way for a transport to find out wether a contact was removed  
> cause of bad design or cause the user did it, an implementor *could*  
> choose to take that into account.
> 
> >> For example, people who switch between Jabber and a legacy network. We
> >> have several thousands of those users.
> >>
> >> But like I said, if we make this into a decent protocol there can be
> >> plenty of other usecases. For example, let's say you're in a long  
> >> running
> >> multiplayer game on a website that has some Jabber interaction. This way
> >> the Jabber "gateway" could automatically add players you're temporarly
> >> working with there, and remove them again when you've removed them in  
> >> the
> >> game.
> >
> > Yeah I also agree it could be nice generic, but for a game I thought
> > Shared Rosters was being mooted for that application. (I'd love to see
> > Stars! for xmpp).
> 
> This is a very simple protocol, not for sharing rosters, but for synching  
> your own personal(ized) roster to your Jabber roster. If you have a game  
> structure where 1 roster is shared with many people, it would make more  
> sense to use Shared Rosters, a distrubuted PubSub architecture and what  
> not..
> 
> > You have a nice user population for testing if you have thousands of
> > users. Luxury.
> 
> Well, I don't know the game, but if you have a personalized roster in it,  
> you can see how this will work. I certainly wouldn't want to clean up  
> "ghost" contacts every time I finish a game.
> 
> Another example for roster-subsync: a gateway that automatically adds  
> contacts to your roster when they are in your proximity. Preferably with  
> an anonymized JID ofcourse. When you get out of range it could remove the  
> contact, but you might want to put in your prefs that any contact you  
> exchanged a certain number of messages with will stay in there for a while  
> or be put to "none" so you don't loose the contact.
> 
> What about a Jabber dating service that automatically puts available puts  
> people that are available and match your critera into a group of your  
> roster? (this is where you could imagine some use-cases with the "from"  
> and "to" sunscriptions too).
> 
> And that's just me thinking up cool stuff we could do with this from the  
> top of my head.. who knows what great ideas someone else will come up  
> with? (maybe the JEP should reflect this a bit, since I'm not sure if you  
> should call these things "legacy" services)
> 
> This isn't gonna work with your current proposal I'm afraid, and while it  
> *could* work with Shared Roster groups (though not with the current  
> proposal), I think that's not just overkill. I also think it's not a good  
> match of technologies. PubSub was not meant to have a whole bunch of items  
> that are secret, have 1 publisher, 1 subscriber and nothing else, used to  
> send presence subscriptions. Shared Roster groups shines at what it's  
> meant for, *sharing* a group of peolpe on your roster with others.
> 
> >> None of this will be accomplished by this proposal, or any other other
> >> proposal, without modifying clients (or servers). Proper synching will
> >> always require new work on protocols. On top of that far from all  
> >> clients
> >> already support jabber:x:roster, and that backwards compatibility should
> >> not be the *deciding* factor when developing new specifications..
> >
> > That is ultimately the main thrust. People change their clients more
> > often than transports change, and transports change a lot quicker than
> > the servers/routers. The main advantage of my proposal is that the user
> > can see all the importable contacts at a glance. Then the stuff that
> > needs to happen can happen without any more user interaction. By no
> > means am I saying my proposal is perfect.
> 
> The user can see them all, yes. But he's supposed to accept all of them in  
> the first place right? Or at least, the subscription request the transport  
> will make later on.
> 
> Like I said, I too appriciate how your proposal (adding contacts, with  
> some meta data) works with existing clients and specs, therefore I see no  
> reason not to use it. The roster-subsync proposal goes beyond what you  
> propose though, and fixes problems your proposal doesn't even begin to  
> look at. Roster-subsync is the right aproach to fixing a problem we want  
> to solve, while your proposal is a way to enhance existing services for  
> some clients.
> 
> >> If you're saying client shouldn't have "none" contacts, you're  
> >> effectivly
> >> argueing that if you have me in your roster, I can delete myself from
> >> that. I think even the legacy networks don't allow that. "none" contacts
> >> are valid contacts. Maybe you just want to look at your vCard sometimes
> >> after I deleted you from my roster. Maybe you decide your roster is too
> >> big and delete me from yours (making you a "none" contact in my roster),
> >> and I decide I'll just request subscription again when I have something
> >> important to say. If I keep the "none" contact, that's very easy to do.
> >
> > As I said, cross purposes. I think the suggestion of a 'your roster has
> > zombies or is haunted' dialogue is sufficient. It is also the domain of
> > the client authors how they wish to handle that.
> 
> Well, the client doesn't know which "none" contact is a zombie, and which  
> one is. Again, if you delete me from your list I don't consider you a  
> zombie contact on mine. If I delete you, and you don't go away, that's a  
> zombie.
> 
> >> >> Would you suggest doing that by JEP-0093 or by sending a subscription
> >> >> request? (not sure what you mean exactly)
> >> >
> >> > OK, I need to work on that bit then. :)
> >> >
> >> > How I had envisaged it was that all 'out of jabber' added contacts  
> >> would
> >> > be sent via the jep-0093 and the mechanism previously suggested. All
> >> > pending contacts not enacted apon would be added using the normal add
> >> > contact use case.
> >> >
> >> > I do appreciate the comments that have been put into your replies, and
> >> > the effort James has spent on documenting his own preffered solution.  
> >> I
> >> > personally don't agree with his approach, hense my proposal, but the
> >> > fundamental thinking and observations behind it are clear and useful.
> >>
> >> The good thing about your protocol is it works for the intial import
> >> (including the meta-data), and "new" contacts later on (including the
> >> meta-data), all with existing protocols and some existing clients.  
> >> Thus, I
> >> see no problems with using it for that.
> >>
> >> It still doesn't do this very automated, and the "flow" won't be optimal
> >> in current clients. The interface will let clients *not* add certain
> >> contacts (and make that seem like a good thing) which could lead to
> >> confusing behaviour for the user, unless you're willing to tolerate a
> >> security risk.
> >
> > I don't see how it is not automated. Well really it depends on the
> > clients and how they implement the semantics for that I suppose, but
> > that is true of any proposal.
> 
> The "adding" is not fully automatic. (roster-subsync: put enough trust  
> into this once, and it'll work from then on without touching it). How none  
> automatic it is from then on depends on client implementation. Some will  
> treat each separate JEP-0093 item as a seperate "attachment" perhaps, and  
> some others might present a list. Some will require to select every  
> JEP-0093 seperatly perhaps, etc. etc. That's just the JEP-0093 part. Then  
> there's the subscriptions. Some users will configure their clients to  
> automatically choose to allow all subscription requests (they'll have it  
> easy), some will choose to allow for every contact they already have a  
> subscription to themselves (so that would be every contact they chose to  
> add from the JEP-0093) if their client has such an option, and some  
> (including me) will choose to have to give permission to *every* contact  
> (the default "safe" behaviour). so could still be a LOT of clicks if your  
> clients supports JEP-0093.
> 
> Don't get me wrong, I'm not saying the number of clicks will be less  
> (they'll be more) for clients that do neither JEP-0093 nor roster-subsync.  
> I'm just saying roster-subsync allows the transport to tell the client to  
> see the difference between adding, removing and changing of subscription  
> states that *already* happend or are effectivly pre-approved, and the ones  
> that are "real" and new that still need the users permission.
> 
> This is also the reason that any proposal attempting to cover all the  
> issues that roster-subsync does, will be more elegant and easy to  
> implement if it uses the <presence/> packet instead of <message/>. This is  
> what most of the data is actually about, which is also why I think from a  
> "clean protocol" standpoint, that's where it belongs.
> 
> >> Then there is the roster-subsync proposal. A new protocol, this does
> >> everything correctly, and can be completly automatic if it's supported  
> >> by
> >> the client. This includes *full* synchronization, including removal.  
> >> Also,
> >> if you implement roster-subsync on the transport, you've automatically
> >> also implemented a system that (with the proper, manual interaction from
> >> the user) will work for *every* client, you just don't get the  
> >> meta-data.
> >
> > Yes that may be true from your perspective, and many other peoples on
> > this list. I find that the roster-subsync proposal is a little too
> > complex and really it only has a function during the importing/
> > transition phase. While my proposal isn't perfect, it does perform the
> > functions required for that phase, albiet with more coding from the
> > client writers than the transport writers but let's keep the
> > intelligence there for this. They can then define how they want their
> > use cases to work.
> 
> I'll emphasize again, for what your proposal can handle -adding some  
> contacts at import and later on- it's good (in fact you wonder why we  
> haven't seen something like this used). Anything beyond that like removal,  
> perfect syncing or real automation it doesn't shine.
> 
> If you as a user or the maker of client are content with that, fine. It's  
> not what I hear from my users, it's not my experiance as client maker, nor  
> that of some off-list contacts who are eager to try this. We also have at  
> least one transport maker that seems to think it's a good idea (who  
> undoubtly is also a user of it). but that doesn't mean *you* have to have  
> the same opinion :) So I don't see your proposal as a reason not to have  
> roster subsync, just like I've never seen roster-subsync as a reason not  
> to have your proposal. Nor did I have the feeling you really did, for that  
> matter.
> 
> >
> >> Could you make a system based around JEP-0093 and <message/> that  
> >> achieves
> >> the same thing? Sure.. but I don't think the protocol will be more
> >> elegant, and I don't believe it will be easier to implement, not even  
> >> for
> >> clients already supporting JEP-0093.
> >
> > That is an assumption you are making, and I am not sure why. I don't
> > think it'll be any easier or harder than roster-subsync, but as I
> > haven't implemented it client-side I don't know.
> 
> It's not a crime to make an assumption when you design a protocol (hell  
> no), as long as you have good reasons to.
> 
> Most of your data will presence related. When you put stuff it in a  
> <message/> you're not making things easy for yourself I think. How will  
> you use JEP-0093 in a way it can handle these new task without breaking up  
> old client using the namespace or having a really ugly protocol? If you  
> already have a framework dealing with presence (JEP-0093 or not, the  
> transport and client have to set these subscriptions!) wouldn't it be  
> easer to add roster-subsync to that rather than a JEP-0093+<message/>  
> mechanism? And finally, if most of your data is related to presence  
> subscriptions shouldn't it be in presence packets from a protocol  
> perspective anyway?
> 
> These are some of the questions I asked and answered for myself.. I  
> haven't seen them answered very differently by anyone yet, so that's what  
> I base my assumption on. But like I always stated, I'd love to see someone  
> try.
> 
> >> If as a transport author also want to support clients that support  
> >> neither
> >> JEP-0093 nor roster-subsync, roster-subsync will *definetly* be less  
> >> work.
> >> However, once you've implemented roster-subsync you already have a lot
> >> done for adding your proposal.
> >
> > Well I've implemented my proposal in a transport and it took exactly...
> > 8 lines of code for the import case. The subsiquent session case hasn't
> > been done yet but it won't take that many lines or add that much
> > complexity. :)
> 
> Let's ask James how many lines it took him to implement his original  
> proposal (the <import/> based one). I honestly haven't asked him yet, but  
> I'm guessing it was less than yours! Would saving a few lines of code be  
> reason for you to ditch what you have now?
> 
> Of course when you have more functionality you'll end up with more code.  
> But when your transport doesn't know the "to" or "from" state you won't  
> have to implement that either. Still it's mostly adding some simple data  
> already known to the transport to outgoing presence packets, and for the  
> clients it's mostly looking at incoming subscription related presence  
> packets a little better for a roster-subsync tag, sometimes automatically  
> sending one back (which some clients already do), and a little prompt or  
> setting for the user if they're OK with this. Not exactly rocket science  
> either..
> 
> >> That's why I think your proposal should stick to what it is now, a
> >> documentation on how to use JEP-0093 to help a client that does not
> >> support roster-subsync but does do JEP-0093 to import new contacts. You
> >> won't have to mention the security problem or the "semi"-removal you do
> >> now, since any roster-subsync supporting transport will take care of  
> >> that,
> >> even for clients that don't support roster-subsync (or JEP-0093 for that
> >> matter) at all.
> >
> > That is probably a good way of looking at it. I don't feel that the
> > security issues or removal issues need to be taken care of specifically
> > other than I have already identified. I have no problem with this being
> > seen for what it is, one way to solve a problem, it isn't the be all and
> > end all, and doesn't try to be.
> 
> I hope all my writing here too has shown that I have no problems with the  
> idea of using JEP-0093 to send some contact, let alone you writing a guide  
> on how to do that. I just think there are many legimate cases out there,  
> which can't be fixed with existing protocol, and that the roster-subsync  
> proposal will hopefully give us a powerfull but simple way to do that.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 




More information about the Standards mailing list