On Saturday 01 Jun 2013 00:23:51 Steve Dougherty wrote: > I've been reading code and documentation, and working on design. I'm > planning what to build first and how it can fit into what already exists. > > I intend to build features so that they are initially functional, if > somewhat clunkier than they could be. This so that something > immediately useful comes of the project no matter what state it is in > when the summer ends. > > Infocalypse should still function without Fred plugins. It should work > with either LCWoT or WoT. [0][1] It should not require WoT or the > Infocalypse web UI Fred plugin (which I also intend to write) for > things other than features which actively require them. To do > otherwise would obnoxiously introduce dependencies. > > From discussing with digger3, it seems automatically discovering > whatever anyone publishes may not be desirable, at least as an initial > goal. The use case of looking through all known repositories is both > unlikely and difficult to implement well. It would be equivalent to > wanting to scroll through all the repositories listed on GitHub. The > use case of finding all forks of one's own repositories seems more > likely, but also similar if not identical in implementation problems.
Right, we can rely on explicit pull requests for this. Which is what github users do most of the time. > > digger3 also said that including edition hints is of questionable > value - that people can be given the relevant edition numbers via > social means when they're first told about the repository. However, I > don't see it as likely to cause problems, and it seems useful enough > for bootstrapping or for popular repositories one is not informed of > explicitly and individually. It could introduce scaling problems due > to inserting the list of repositories each time one is updated, but I > can't think of problems other than that, and it doesn't seem severe. > My assumption here is that identities will only publish a small number > of different repositories. Is this reasonable? Probably. > > SomeDude mentions that the Fossil SCM has things like a wiki and bug > tracking already, and asks that the Fred plugin be VCS-agnostic. [2] > This is a good thing to do - it would mean adding a layer of semantic > abstraction, though it introduces a danger of overengineering. Any > easy part of this is adding a "vcs" property in published repository > entries. I'm reluctant to try to develop an extension for Fossil SCM > instead of patching Infocalypse because: > > 1) Mercurial already has a Freenet transport through Infocalypse. > 2) my mentor ArneBab has experience with Mercurial, Infocalypse, and > b. [3] I suspect it would be difficult, because they work in different ways. OTOH Fred is likely to continue using git for the foreseeable future. No opinion really. > > My proposed design for the first set of changes: > > Someone's WoT identitiy has "vcs" context. > USK@WoT-ID/vcs/ holds an XML file containing in part: > > <repository vcs="Infocalypse">USK@WoT-ID/reponame/edition/</repository> > <repository vcs="Infocalypse">USK@key/reponame/edition/</repository> > > Pull requests are at USK@WoT-ID/vcs-pull/ > > <pull vcs="Infocalypse" to="USK@key/reponame/">CHK@key</pull> > > where fetching the key gives something like a collection of > email-formatted diffs. It would be nice for Infocalypse to allow > checking this with "hg incoming" or similar. I hope there will be proper bundles etc. We want this to be efficient. > > Infocalypse commands need wider support for using WoT IDs. I've > implemented initial support for using --wot in place of --uri for > fn-create. --uri takes something like USK@/reponame.R1/0, whereas > --wot takes enough of a nickname to be unambiguous instead of "USK@". > It requires lib-pyFreenet. I've inserted it under my WoT identity with > a mirror at BitBucket. [4][5] For example, I used hg fn-create --wot > oper/wiki_hacking.R1/0 to insert under my WoT ID operhiem1. > > I hope this wasn't too long-winded, and please let me know if you have > questions or comments. Cool! > > Thanks, > operhiem1 > > [0] https://github.com/tmarkus/LessCrappyWebOfTrust > [1] https://github.com/freenet/plugin-WoT-official > [2] http://www.fossil-scm.org/ > [3] http://www.digitalgemstones.com/projects/b/ > [4] > USK@pxtehd-TmfJwyNUAW2Clk4pwv7Nshyg21NNfXcqzFv4,LTjcTWqvsq3ju6pMGe9Cqb3scvQgECG81hRdgj5WO4s,AQACAAE/wiki_hacking.R1/1 > [5] https://bitbucket.org/operhiem1/wiki_hacking > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
