I'm not getting what this is for. It seems to be something about automation around arbitrary people on the Internet giving you work to do. It seems like this is a flaw to get rid of? Email and bug trackers make it all too easy.
Global Task Exchange Protocol
21–29 of 29 posts
Re: Global Task Exchange Protocol
#22I'm not getting what this is for. It seems to be something about automation around arbitrary people on the Internet giving you work to do. It seems like this is a flaw to get rid of? Email and bug trackers make it all too easy.
Partially I agree with you. This is to get rid of the hacks people do to work across organization wall.
Let me try to explain: A task is not just a text, it has context and history, and meta data. Unfortunately people use email for this which creates 100s of messages in a thread. Instead, if you keep single entity and keep updating it like you would do in any task management system, it will create better meta data and less headache to manage.
Re: Global Task Exchange Protocol
#23I'd follow along with what the IndieWeb folks are doing. They've got a pretty good principle of reusing existing infrastructure in new ways to build interesting things without needing coordinated upgrades.
As an example, getting widespread adoption of a new TX DNS record type is unlikely, though you can fake it with TXT records.
Re: Global Task Exchange Protocol
#24I'd follow along with what the IndieWeb folks are doing. They've got a pretty good principle of reusing existing infrastructure in new ways to build interesting things without needing coordinated upgrades. As an example, getting widespread adoption of a new TX DNS record type is unlikely, though you can fake it with TXT records. https://indiewebcamp.com/Category:building-blocks
> though you can fake it with TXT records.
That is right. I will update the proposal thanks!
Thanks a lot for the suggestion. I love what IndieWeb is doing.
Re: Global Task Exchange Protocol
#25Earlier quoted context omitted.
Amazing, I think if we keep identity management as a part of configuration then it will be easier for development, till one protocol becomes standard. I will try to add this as a default identity management. Thanks for the link.
Our group is responsible for building and maintaining 108 applications. We were tired of building user-permission systems into every application, so standardizing our user and group system around SCIM solved half of the problem. For a standardized way of managing roles-permissions, we've adopted the ANSI RBAC [1] standard. The Apache Directory project's Fortress [2] sub-project is compliant with the ANSI RBAC specifi…
User roles-permission is indeed a complicated problem to solve. But do you think this will need so much complication?
As far as I think, it is straight forward. But I also agree when you work in a complicated hierarchy, you probably need these systems.
Re: Global Task Exchange Protocol
#26Earlier quoted context omitted.
Our group is responsible for building and maintaining 108 applications. We were tired of building user-permission systems into every application, so standardizing our user and group system around SCIM solved half of the problem. For a standardized way of managing roles-permissions, we've adopted the ANSI RBAC [1] standard. The Apache Directory project's Fortress [2] sub-project is compliant with the ANSI RBAC specifi…
User roles-permission is indeed a complicated problem to solve. But do you think this will need so much complication? As far as I think, it is straight forward. But I also agree when you work in a complicated hierarchy, you probably need these systems.
No ... I don't think you would need roles and permissions for the task project but since you were enthusiastic about the user and groups I thought I'd pass along a solution for a comprehensive (but external) user management system.
EDIT: I also should have mentioned that we're updating our original system to be compliant with the specification and open sourcing [1] the code that's not custom to our application.
Re: Global Task Exchange Protocol
#27I'm not getting what this is for. It seems to be something about automation around arbitrary people on the Internet giving you work to do. It seems like this is a flaw to get rid of? Email and bug trackers make it all too easy.
Partially I agree with you. This is to get rid of the hacks people do to work across organization wall. Let me try to explain: A task is not just a text, it has context and history, and meta data. Unfortunately people use email for this which creates 100s of messages in a thread. Instead, if you keep single entity and keep updating it like you would do in any task management system, it will create better meta data an…
Okay, but switching to a better issue tracker (for your needs) seems considerably more practical than solving data interchange between issue trackers.
Re: Global Task Exchange Protocol
#28I'd follow along with what the IndieWeb folks are doing. They've got a pretty good principle of reusing existing infrastructure in new ways to build interesting things without needing coordinated upgrades. As an example, getting widespread adoption of a new TX DNS record type is unlikely, though you can fake it with TXT records. https://indiewebcamp.com/Category:building-blocks
It sounds to me like the OP is actually looking for SRV records, which are basically generalised MX records.
Re: Global Task Exchange Protocol
#29I'd follow along with what the IndieWeb folks are doing. They've got a pretty good principle of reusing existing infrastructure in new ways to build interesting things without needing coordinated upgrades. As an example, getting widespread adoption of a new TX DNS record type is unlikely, though you can fake it with TXT records. https://indiewebcamp.com/Category:building-blocks
It sounds to me like the OP is actually looking for SRV records, which are basically generalised MX records.
For now TXT records will work, till it becomes a stable one, then it can be moved to either SRV or its own set of records