Difference between revisions of "Bitgroup/Tasks"
(→Task#13 (2013-09-26): state, SWF) |
(→Task#13 (2013-09-26): need to untify the informtation routing) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Tasks todo == | == Tasks todo == | ||
| + | === Task#15 (2013-10-15) === | ||
| + | When member online information is dynamically present in the interface, a new discussion view can be started which allows basic real-time chat between the online users. This can then be stored periodically in the group data so that other users can see it when they come online later. | ||
| + | |||
| + | === Task#14 (2013-10-15) === | ||
| + | After the state data is working with the SWF connections, the overview should then render a live table that has the group members listed with a column for their current online information and status. | ||
| + | |||
=== Task#13 (2013-09-26) === | === Task#13 (2013-09-26) === | ||
<s>If the interface is connected to the server via SWF, then it shouldn't be calling sync, the changes should be sent immediately.</s> The state data needs to work with SWF, currently it's only sent in response to _sync requests. | <s>If the interface is connected to the server via SWF, then it shouldn't be calling sync, the changes should be sent immediately.</s> The state data needs to work with SWF, currently it's only sent in response to _sync requests. | ||
| + | |||
| + | This was mostly completed, but then there is also now the routing of the peer online info between the peers which has also been done (this differs from normal change routing because it doesn't store in the node data and is not tied to a group). | ||
| + | |||
| + | But there is a lot of duplication going on here because there are now three separate aspects of routing data between connections (data synchronisation, application state and peer information). These really need to all be combined into the data synchronisation and have arrays that determine which root keys of the data should be treated differently - i.e. which are local only (routine only to the local interface connections such as the application state data), and which are not to be stored (both the application state and the peer online information). | ||
=== Task#12 (2013-09-22) === | === Task#12 (2013-09-22) === | ||
Interface instances need to assess idle time and not bother doing sync requests during that time. | Interface instances need to assess idle time and not bother doing sync requests during that time. | ||
| − | |||
| − | |||
| − | |||
=== Task#9 (2013-09-17) === | === Task#9 (2013-09-17) === | ||
| Line 34: | Line 41: | ||
'''Completed (2013-09-20):''' Done, but the labels needed to be stored in the group's data because labels can't be set for determanistic addresses via the API. | '''Completed (2013-09-20):''' Done, but the labels needed to be stored in the group's data because labels can't be set for determanistic addresses via the API. | ||
| + | |||
| + | === Task#10 (2013-09-18) === | ||
| + | Need to change the dataSync method slightly to guarantee that only one sync is occurring at once. If the server or browser is too slow with one request, then the next can occur at the same time and begin to clog up the pipe. A simple syncLock property would do it that's set at the start of the sync and reset on success or error. | ||
| + | |||
| + | '''Completed (2013-09-19)''' | ||
=== Task#7 (2013-09-17) === | === Task#7 (2013-09-17) === | ||
Latest revision as of 14:28, 21 October 2013
Tasks todo
Task#15 (2013-10-15)
When member online information is dynamically present in the interface, a new discussion view can be started which allows basic real-time chat between the online users. This can then be stored periodically in the group data so that other users can see it when they come online later.
Task#14 (2013-10-15)
After the state data is working with the SWF connections, the overview should then render a live table that has the group members listed with a column for their current online information and status.
Task#13 (2013-09-26)
If the interface is connected to the server via SWF, then it shouldn't be calling sync, the changes should be sent immediately. The state data needs to work with SWF, currently it's only sent in response to _sync requests.
This was mostly completed, but then there is also now the routing of the peer online info between the peers which has also been done (this differs from normal change routing because it doesn't store in the node data and is not tied to a group).
But there is a lot of duplication going on here because there are now three separate aspects of routing data between connections (data synchronisation, application state and peer information). These really need to all be combined into the data synchronisation and have arrays that determine which root keys of the data should be treated differently - i.e. which are local only (routine only to the local interface connections such as the application state data), and which are not to be stored (both the application state and the peer online information).
Task#12 (2013-09-22)
Interface instances need to assess idle time and not bother doing sync requests during that time.
Task#9 (2013-09-17)
Proper notification system for messages on the page, so that notification comes up in all instances until the notification is closed.
Task#8 (2013-09-17)
The extensions and the node data need to be in their own dir rather than just a named file. Extensions can then be packaged with their own resource files such as images etc. Also the extension should be able to have it's own i18n file instead of having to call msgSet so that it's easier for non-developers to help maintain the messages.
Task#6 (2013-09-17)
Treeview component that can be dynamically connected or not (i.e. just setValue without connect)
Task#4 (2013-09-17)
Group invitation and acceptance mechanism.
Task#3 (2013-09-16)
Add group creation view and a template data structure for new groups. Group creation can only work if both the Bitgroup and Bitmessage daemons are running, so it must bring up a message advisng the user to start them if they're not both running. Since the connected state of both is in the dynamic state data, events can be set up so that the group creation form can render as soon as the connected state is corrected.
Tasks done
Task#5 (2013-09-17)
Password authentication to protect from XSS in Ajax requests to the application from remote sites.
Completed (2013-09-23): Used HTTP digest auth with user and pass for interface specified in the .config file.
Task#11 (2013-09-18)
The available groups are still just a hard-coded array. Need to get them drawn from the BM-addresses in the data dir and get their labels from BM.
Completed (2013-09-20): Done, but the labels needed to be stored in the group's data because labels can't be set for determanistic addresses via the API.
Task#10 (2013-09-18)
Need to change the dataSync method slightly to guarantee that only one sync is occurring at once. If the server or browser is too slow with one request, then the next can occur at the same time and begin to clog up the pipe. A simple syncLock property would do it that's set at the start of the sync and reset on success or error.
Completed (2013-09-19)
Task#7 (2013-09-17)
Change i18n messages to JSON and load from both JS and Python sides.
- Completed (2013-09-17)
Task#2 (2013-09-12)
Detect connectivity status with the Bitgroup service and the Bitmessage application and report in the interface. Queue up data synchronisation changes until the service is back online if it's not connected.
Completed (2013-09-15)
Task#1 (2013-09-10)
Create default skin based on OD site.
Completed (2013-09-16)
