On Wed, Aug 29, 2012 at 10:39:29AM +0200, Olivier Berger claimed: >Hi. > >Travis Brown <[email protected]> writes: > >> On Tue, Aug 28, 2012 at 10:25:13AM +0200, Olivier Berger claimed: >>>Have you considered OSLC-CM (Open Services for Lifecycle Collaboration >>>Change Management) specifications [2] ? >> >> After a quick glance it looks to me that the protocol is designed with >> real time bidirectional communication in mind (ie. an HTTP >> session). Are you familiar enough with the protocol to comment on any >> obvious impediments to using it, in a restricted manner perhaps, over >> an asynchronous protocol such as email? > >I think there's the protocol part which specifies the behaviour of >service and client operating over a REST API (including AJAX dialogs for >delegated stuff, compact preview, etc.). > >Then there is the RDF representation of the bugs (Change Requests). > >I don't see why that last part wouldn't fit for email transfer of bug >properties. At least for the generic properties [0], it looks very >similar to what you described, I think. > >See for instance a fictional sample in turtle format : >http://open-services.net/bin/view/Main/CmSpecificationV2Samples#Request_with_no_parameters_as_Tu >I can imagine quite well such text content inside an email without too >much decoding issues (other that your preferred language's library for >RDF/Turtle parsing... hint: rdflib supports turtle for Python). > >I think I'm quite familiar to OSLC, but then I'm not sure I understand >what you try to achieve (I may have over read and forgotten... oh, look, >your home page suggests https://github.com/travisb-ca/nitpick ;-) >
My immediate goal is to add bug import/export capabilities to my pet distributed bug tracker Nitpick. I use Nitpick is several different ways, one of which is as a local 'mirror' of bugs in other projects I am interested in. Currently I do this manually, but it'd be nice to automate this. This got me thinking about the type of interactions I'd like to support. Of course there is the online synchronous connection where you directly contact the other bug tracker. However, many bug trackers already support emailing out bug updates when they change. Receiving this update email automatically when my laptop is connected is nicer than having to poll every bug tracker I follow whenever I think there may be a bug update. Thus I think it would be very useful to support asynchronous push transfer protocols like a subscription email list. I also think it is important to support partial updates because a bug can get fairly large and good bandwidth is not always available. It may also reduce the difficulties in merging different views of a bug by not transferring redundant data which may have changed in the receiving tracker, but not the sending tracker. I took at look at OSCL-CM and OSCL-Core last night. It's bit more verbose then my proposal, but that's to be expected from a more flexible spec. My only concern is how to transfer comments on a bug inline. From my reading it seems that it should be possible, but will likely need at least one additional field in order to be robust. I stumbled upon [0] yesterday which pressed home the need for some depth in the comment threading information. OSCL doesn't seem to include this as part of the existing spec. >-- >Olivier BERGER >http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 >Ingenieur Recherche - Dept INF >Institut Mines-Telecom, Telecom SudParis, Evry (France) [0] http://www.jwz.org/doc/threading.html _______________________________________________ dist-bugs mailing list [email protected] http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
