enhancement(revit): persisting applicationId from Revit receive and send

dtnaughton commented 1 year ago

Prerequisites

[x] I read the contribution guidelines
[x] I checked the documentation and found no answer.
[x] I checked existing issues and found no similar issue.
[x] I checked the community forum for related discussions and found no answer.
[x] I'm requesting the feature to the correct repository (see also speckle-server, speckle-sharp, specklepy, speckle-docs, and others)

What package are you referring to?

speckle-sharp

Is your feature request related to a problem? Please describe.

We have a project workflow that involves sending lighting fixtures between two different Revit models, and requiring the ability to seamlessly update the objects bilaterally. Currently, when objects are sent from model A, they are assigned an applicationId based on the revit element unique Id.

When receiving into model B, some changes are made to the object with the desire to send these objects back to model A to update (e.g. family/type, location). On conversion of these updated objects to speckle objs (of type RevitInstance), a new unique Id (from Revit) is assigned. Therefore, there is no continuity of applicationId which prevents Update functionality on receiving back to model A.

Describe the solution you'd like

On receive, a check is done on previouslyReceivedObjects stored in the StreamState to enable update functionality. Has it been considered on the send operation to also check if there are any previously received objects with revit unique ids stored in createdIds on the ApplicationObject, and if so, maintain the applicationId from this object? This would aid the bilateral movement of objects.

I would be interested to hear if this would pose any wider issues for the create/update functionality or if there are any other reasons this wouldn't be a good idea!

Describe alternatives you've considered

Additional context

Related issues or community discussions

teocomi commented 1 year ago

Hey Dan, Speckle has not really been designed for this sort of round tripping (this is how we call this workflow internally). Every time you receive in a software, a whole new element is created, and we're not trying to preserve the association between them beyond an A=>B flow. Going full circle is misleading; think of when a Revit wall is received in Rhino; sending it back to Revit will just cause problems if we try updating the original one...

Having said this, we know round tripping could unlock even further workflows, and have discussed at length how eventually it could be enabled (but maybe not encouraged) at a technical level. One promising solution would be to attach an originalAppId next to the applicationId property the first time we send an element, and that's never removed or altered. When receiving, the update logic could check on both the applicationId AND the new originalAppId fields... We even have a fancy diagram:

dtnaughton commented 1 year ago

Hey Matteo - thanks for the prompt response!

Good point r.e. object type mutating. I think in cases where the object type mutates, it's understandable that the situation becomes difficult because of the lack of similarity between objects. In cases where the object type is not mutated (e.g. a Revit -> Revit workflow, or a platform that wouldn't convert the object to another type), I think the implementation using an originalApplicationId property would make a lot of sense. Perhaps performing a check on changes to object type could also form part of this implementation.

Are internal discussions ongoing regarding this issue, or is it parked for now?

teocomi commented 1 year ago

It's temporarily parked - but happy to revisit once we have a stronger need for this feature...

Perhaps performing a check on changes to object type could also form part of this implementation.

Good idea :)

Jeroen-de-Bruijn commented 1 year ago

Thanks Matteo, we have a project team that has a strong need for this feature. They are very interested to explore the round trip workflow for a large project. They have two Revit models (architectural and electrical) and want to exchange light fixtures between them. This issues was also brought up by the project team: https://github.com/specklesystems/speckle-sharp/issues/2438

Just to set clear expectations to the project team, any chance this feature will move forward in the near future? Or will it remain in parking lot for now?

teocomi commented 1 year ago

Hey Jeroen, I've pinged you on discord, let's chat there!

Jeroen-de-Bruijn commented 1 year ago

The project team and I drafted the specific workflow from a user point of view in more detail, which hopefully helps to provide context.

The workflow consists of 2 parts and is aimed at lighting fixtures in 2 Revit models. The architect defines the location and the electrical engineer specifies the technical parameters. Interesting to note that the family name and type name are the same in both models, but the family in the architectural model is a stripped down version from the electrical one so the architect can just focus on the location and don't worry about the other parameters.

Revit architectural model > Revit electrical model
Revit electrical model > Revit architectural model

Speckle round trip

Jeroen-de-Bruijn commented 9 months ago

What is the current view on looking into supporting round trip workflows?

specklesystems / speckle-sharp