![]() |
Bartosz Małkowski opened 4 years ago
|
![]() |
Module is implemented and available ink |
|
@sevan.evans Tags here are what we call Pins in the client app code. Pins are currently implemented as a mockup and hardcoded. With the server side support and library support we can now have proper and full implementation in the client. For more details, please refer to ticket kangaroo-76 where we discussed all the details. It is very lengthy discussion I would suggest to start reading it from the end. Some additional information can also be found in the document here: https://github.com/tigase/kangaroo-tigase-extensions/blob/master/docs/tagging-jids.md |
|
Got it, I'm on it. Sevan {cut >>>}On Fri, Mar 26, 2021, at 3:41 PM, Artur Hefczyc wrote:
|
![]() |
Documentation moved; now found at https://github.com/tigase/kangaroo-tigase-extensions/tree/master/src/main/docs |
|
@wojtek @andrzej.wojcik @bmalkow At the moment we have 2 repos with documentation: Maybe we could have just one repo with docs? |
|
Sorry about that @sevan.evans , I was moving things around to make the structure more logical. @kobit
Actually we currently have 3 repositories - there is additional https://github.com/tigase/kangaroo-tigase-extensions-systems/ with extensions for the actual deployed systems (I would like to rename |
|
Hm, I am thinking and I am not sure. More logical is to keep documentation close to the source code, so everything is in one place. It does not make much sense to combine all these repos into one either. Let's have the main/master/generic documentation in the kangaroo repo and the code specific documentation in the same repo where the source code is. However, we need somehow to have one place with links and some basic info about each part. @wojtek Could you please update README.md file in the Kangaroo repo with information about all other kanagroo repos with links to them and basic (1-2 sentences) description what these other repos have? |
|
I think the approach with having documentation in 3 places makes sense - extensions may evolve quicker / have versions and having relevant documentation there (tied to the particular sources version) makes the most sense (we use same approach in our other repositories). @kobit I updated repository readme as per instruction. |
|
thank you. |
Type |
New Feature
|
Priority |
Normal
|
Assignee | |
Spent time |
23h
|
Subsystem |
Client
|
Tags for users and channels - protocol specification