No way to represent internal session state without joining session

[jwittner]

I have a use case where I want to display some modifiable state of the session on a list of the available sessions. The state can't be contained in the name of the session because session names cannot be changed after creation.

I'm thinking of adding an API to request sync data via URI like paths relative to the Root sync element - e.g. "my/special/data". The result can provide a const Sync::Element interface for each requested path. One could provide a list of these sync paths in the ListSessionsRequest.

Thoughts? I'll probably start heading in this direction soon.

[jwittner]

Ok, we've made some progress on this. To simplify the integration we're starting with a brand new request/reply QuerySessionSyncData* for requesting elements of the Sync::Element hierarchy.

We'd like to provide an API to C# for requesting multiple URIs at once by filling out an array in some form. We tried C++ pointers/arrays, references, and stl vectors. I've ran through much of the SWIG documentation now for C#, arrays, and stl vectors.

• Arrays, pointers, references, etc. generate an odd SWIG_ type.
• STL vectors generate the name I specify, but not the associated class for that name.

Anyone out there skilled with SWIG and arrays? Had luck generating an interface with such an API?

[jheuvel-ms]

Hey Josh,

I've got some concerns about adding support for getting the sync data from a session without having the user join a session, as it bypasses the opportunity for us to authentication that the user is able to access the data in the session.

We (internally) had talked some time ago about having the ability to add app-defined meta data to the session definition so that you wouldn't have to do the trick with encoding the information in the name of the session. I feel like this would be a simpler and more secure way to achieve what you want, without having to expose the sync data outside the session.

[jwittner]

@jheuvel-ms That makes a lot of sense to me. How were you thinking one would define the meta data? I'm thinking I could easily extend the session creation request to include metadata and then always pass that to users when report about sessions?

The issue I have with this is that the state I have wants to be nicely syncronized between clients that can modify it once in the session. Perhaps the session could include a white list of sync uris available to any requester? Then I could even report the data on ListSessionRequest calls automatically too.

[jheuvel-ms]

Ok, so let me make sure I understand your goals:

• You want to be able to allow users outside of a session to have some additional information about the session
• The additional information can change during the life of the session
• You want to take advantage of the sync system's conflict resolution to gracefully handle changes to this additional information from multiple users

Is that right? Who can and can't change the metadata? Can only people in the session change it, and people outside the session only read it? How big is the metadata, can we set a cap?

[jwittner]

@jheuvel-ms You've nailed my set of desires. Only people in the session can modify, with externals getting read-only queryability. I think it'd make sense to limit it to a few entries, right now we look at less than 5.