On 10 September 2016 at 01:00, Jan Kandziora <j...@gmx.de> wrote: > Am 08.09.2016 um 22:32 schrieb Johan Ström: >> >> .. what else? >> > First: I'd love to get rid of are these personal blogs who give stray > information bites which are quickly outdated and totally out of control. > This is the source of most misfortune for owfs users. I'm pretty sure > only 1 of 10 shows up here at the mailing list and ask us. Nine of ten > people will give up or just live with their brittle setup. > > > I have to admit: I personally hate those people who endlessly copypaste > that blurb about using a pullup of 4.7k to 5V on the Raspberry Pi GPIO4. > > The simple reason people can tell this is because... the authoritative > source of information... our site... had nothing about this. Or at > least, it's covered by layers and layers of owfs internals which sound > like nonsense to anybody but us developers. > > > Same with using the FUSE binding. People endlessly copypaste blurbs > about using the FUSE binding. > > We really, really should say people: Hey, we have a FUSE binding, it's a > nice technical demo. But it turned out using FUSE for pseudofilesystems > is a bad idea because of race conditions so... don't do that. Forget > that thing exists. Thank you. > > > The SWIG bindings, our next construction site. People usually *don't* > know there are at least three python bindings to owfs for example, with > the best one OFF-SITE. Or what the difference between owlib, owcapi and > ownet is. > > > And our zoo of host adapter options has to be explained. Simply. When to > use which host adapter. > > > And we should make people interested in owfs look right and left, too. > The w1 kernel driver can make them happy, too (for example for using the > DS28E17). The owfs external mechanism on the other hand can be used to > put GPIOs into OWFS, which makes owserver some sort of Network I/O > expander. And the two can be combined, making arbitrary I²C sensors into > network-enabled owfs nodes with very little userspace code. > > >> >> Jan, your last lines talked about alternative to push/pull content. A >> github hosted page could actually be edited directly in the github UI, >> there is a Edit button which opens an editor directly. You'd of course >> have to fork it first, and you still need to do basic markup. >> But if instructed how to do it, is that too advanced? >> > Not too advanced. > > My concern was: For end users, the biggest hurdle would be additional > software. They usually don't care about the markup, we have to fix that. > > We need to have a documentation project where end users can easily edit > pages and we have bit of control about what is written there, so > outdated and wrong information cannot live forever. That's why I want to > encourage end users to document their owfs related stuff at a central > site. So we can maintain it. > > This should be seperated from "official" documentation but in a way the > difference is only sublime. So people see "Hey, my owfs project is > recognized by the owfs people. Great!" > > > So, having two wikis, one along the official sources and one for end > users would be great. > > I think we can push wiki pages created from manpages etc. so this will > make Colin and Stefano happy too, I think. > > > Okay? Can we settle on this? Or continue discussion?
As a user who was confused by the vast array of outdated or just wrong information around the internet on using OWFS I wholeheartedly agree with all the above points, except that I suggest there is no need to have two separate wikis. I think that will just add confusion to the user about where to find what. Is there really a need for two? Why not just have everything in one? Regards Colin L. ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
