Speckle Clients - Detailed log of model changes

Hi Speckle,

I’ve been running some small tests with the Revit client (using data created by Grasshopper), and I’m loving how smoothly the update procedure seems to be going.

I personally like to receive a lot of info on what exactly a script is doing in the background (it boosts confidence in the app): for example in Revit, which elements are being created, which are being modified (+ type of change), and which are being deleted. And most certainly, for which elements something unexpected happened…
Do you see value in creating detailed logs about what the Speckle clients are doing to the host apps model (possibly as tabular data for easy searching and filtering)?

Enjoy the weekend!
Kelvin

4 Likes

Yes, I like the idea!
Maybe a first start would be to just dump all the info in a log file where advanced users can have a look? Or is there already such a log file?

There is the Speckle.Core.Logging class, but I think it is currently only sending Exceptions to sentry.

1 Like

Hi there! Sorry for the delay on jumping into this… :sweat_smile:

We currently log a bunch of stuff into Sentry, but as you’ve already seen, it’s mostly for exception related issues, and things get logged (and anonymised) to our private Sentry so none of you guys will actually be able to see any of that.

I think some sort of log would be a great addition, so I’ll discuss it over with the team to figure out if/when/how to fit it in our roadmap.

Just to expand this discussion further. What would the ideal solution be for you guys? Since nothing is coded feel free to propose anything!
Would a single log file where everything get’s dumped work for you? Or would you rather have “per connector”/“per stream” logs?

I also think some of this information (elements updated, deleted, skipped etc) would be useful to many end-users, so it could potentially be good to expose it via DesktopUI as well.
What do you think?

Ideally a user would have a nice desktop UI with an overview of what happened in the send or receive process. So yes, how many elements were successfully send/updated/received, what errors or warnings occurred, etc.
It would be good to save this data in a log file so it could easily be checked by others afterwards. Maybe you need a log file per connector because you could be brave and try to send and receive data in various software simultaneously. This might result in both connectors writing to the same log file at the same time, which could be messy.

2 Likes

Yes, exposure in the desktop UI will surely be useful. A well-informed user is a good user. Indeed you could add a summary of amount of elements that were created / deleted / changed / skipped, and expand these to list all elements with their Ids (perhaps grouped by category, …). To make it fancy, you could perhaps add a link for each element that allows you to immediately zoom into it in your view (similar to the Dynamo Player).

I agree. If it is stored as tabular data then I wouldn’t split it up too much. A big table is always easy to filter through using Pivot Tables and simple to plug into dashboards to make some neat charts.

2 Likes