ah, thanks @goob I didn’t realise this, will check that out!
It’s still a third-party tool 
Something like this should be in the future integrated to the Foundation™ and officially supported in the code.
Also I’m fantasizing of a link in posts to take the user to “the post on my pod”. For example when someone gives me a link to a post on another pod, I click it, I cannot reply or reshare unless I find it on my pod. Just needs some ajax query, and of course post must exist on the other pod.
Has this descision https://www.loomio.org/discussions/612?proposal=463 been worked into GitHub issues? Or how will it be moved into actionable items?
@wilhelm , Florian’s code, linked on this thread, is the start of the solution to the proposal you link to. See https://github.com/Raven24/diaspora-federation
alright, I’m quasi-finished with what I had planned to include in the gem.
Only one more design/architectural issue I’d like to bring up and solve with the wisdom of the crowd:
We have a lot of XML in the protocols around D*, so I have chosen the ‘ox’ gem to handle XML parsing and generation. It promises to be fast and has all the features we need…
Except for one occasion, where we use hCard - which is HTML and uses classes to label its data fields inside standard HTML elements. Ox doesn’t know CSS or XPath selectors, so I can’t select the elements based on the used class names directly. At that point I brought in libxml-ruby, which has support for XPath, which is enough to solve the problem in this case.
Personally I feel it’s unclean to include another lib just for that one use case, and now I’m torn between leaving it like that, or just switching to libxml or possibly nokogiri entirely…
Ideas?
I think we should switch to Nokogiri. While it may not be the fastest library, it’s the most feature complete and battle tested one, so using it should be future proof.
@florianstaudacher – I don’t really know much about the various libs themselves, but I agree that it feels dirty to include a separate lib for just that case. My first instinct is to modify ox so it could support that use case and then we only have to use one lib. Would this be feasible?
If you feel that ox performs better for the other cases, it might be worth considering whether Diaspora’s hCard could be parsed using XML. I’ve had a look online and found suggestions that this is possible with hCard. This may not be a good idea in Diaspora’s case, or may not be a clean solution in itself, but if you’d prefer to use ox, it might be worth considering whether it could work.
Apologies if I’m speaking out of turn, not really understanding the technical issues. It just struck me as a potential alternative approach to switching libraries, if you really like that particular gem.
Well, as far as performance goes, our XML documents are at most a few KB in size, so any speed variances should be almost undetectable.
Modifying Ox to support advanced selectors is way out of scope for this task and I don’t think it’s in the spirit of the lib - being mostly fast and lightweight.
I thought about parsing the hCard as XML, but I decided against it, since the idea behind XML is structure and hCard as such has no structure.
I guess I’ll be moving to Nokogiri, it seems the least controversial…
(in case anybody missed my post on d*)
okay, porting to nokogiri is done. now it’s time to give the code a thorough review. so if you have any ruby knowledge, look it through and give me feedback on anything that might jump in your eyes.
documentation and readme will follow later
I’ve just started a new discussion with some ideas for adding the possibility of pulls to Diaspora’s push model for federation. I didn’t want to start a new discussion on this thread, which might confuse things.
Hope it’s useful.
I created a new discussion for what protocol we use & working with other social networks:
another update: the Readme contains more infos, and I think the docs should be mostly finished.
So if you get a chance, you can have a look at the docs (http://rdoc.info/github/Raven24/diaspora-federation/master/frames) and tell me if everything is understandable and usable for implementing the gem.