OSArch Community

OSArch's own GIT hosting service

  1. T by theoryshaw on 4 Dec 2024, edited 4 Dec 2024 #

    @Nigel said:

    It would be good to provide an elevator pitch so I and maybe others understand what is being proposed

    I'll try and take a one sentence stab... :)

    The OSArch hub would enable concurrent and distributed version tracking and merging of IFC files--as long as it's done in a NativeIFC way.

    ...

    I too agree the focus should center around NativeIFC--and work outward from there.

    Would say, however, with using things like LFS, storing blob files (PDFs, Videos, etc.) with GIT is getting pretty straight forward in my experience.

  2. T by theoryshaw on 4 Dec 2024 #

    My personal mission is to get @dimitar to use it. ;)

  3. B by brunopostle on 4 Dec 2024 # +1 votes

    @theoryshaw said:

    Would say, however, with using things like LFS, storing blob files (PDFs, Videos, etc.) with GIT is getting pretty straight forward in my experience.

    It feels like a misuse of git to store generated files, ie. PDF drawings sets. For instance whenever I have cloned one of your repositories to learn something from your work, it has involved downloading gigabytes of git database that I didn't need.

  4. S by sjb007 on 4 Dec 2024 #

    I agree strongly with @brunopostle regarding not storing generated output files in the repository when they can be created from the source files. I too have hesitated at the initial download sizes of the OpeningDesign projects. Not so much from my storage requirements, but more from cringing slightly at the additional load I'm placing on the server/bandwidth that someone else is paying for. My own .gitignore has patterns for png, svg & pdf in drawings and sheets folders, as I know I can recreate these. Obviously there are other massive "source" files like site videos, external materials, or point cloud meshes etc., that balloon the repository size anyway.

    The question becomes whether git is an appropriate collaboration tool for organisation across multiple companies where you get into legal/contractual/handover/approval/sign-off type stuff. I'm not in the industry, but I'd say git is distinctly lacking there.

  5. T by theoryshaw on 4 Dec 2024, edited 5 Dec 2024 # +1 votes

    I could be missing something, but as i understand it, if you use LFS, it doesn't store the blob in git history, it's just a pointer. The actual file is stored in a more blob friendly storage.

    ...

    I've never done it yet, but i think you can pull down from a repo, and exclude the download of all the blob files, if you want--if looking to save bandwidth.

  6. T by theoryshaw on 5 Dec 2024 #

    I would not underestimate the complexity of launching such a project, though, and various misuses that can happen. Allowing unlimited projects for example without any control, even from a paid member, could become a problem.

    I would agree. Thinking we can play this by ear, as things evolve.

    ...

    As part of simple 2nd phase, would it make sense to set up authentication through Vanilla Forum? That is, anyone that has a login for https://community.osarch.org/, has a login for hub.osarch.org, as well?

  7. A by aothms on 6 Dec 2024 # +1 votes

    I think it makes a lot of sense to start some sort of initiative under the ifcopenshell umbrella for something CDE-like: to cater to a new category of devs and to get ifcopenshell's rich ecosystem of tools available to a wider variety of end-users.

    But we have some technological choices to make:

    1)

    2)

    • IFC access through Python

    • IFC access through WASM

    • Other/mixture

    3

    • Existing initiatives to connect to such as forgejo / openproject / ...

    • Is 'it' a stand-alone project or a plug-in (I can imagine that some 3D viewing functionality for specific file formats is a nice addition to general hosted version control platforms)

    I would say it makes sense to figure out some use cases to prioritize and draw an ecosystem map. In the end development will likely happen more organic and bottom-up, but setting out a vision might help to inspire some first contributors (even if they disagree https://xkcd.com/386/)

  8. B by brunopostle on 6 Dec 2024 #

    @aothms a file storage backend for IFC models makes sense if you are doing standard 'open bim' (where IFC models are basically snapshots shared as a reference, the real models live elsewhere).

    For those doing Native IFC, git forges are ideal (even without fork/merge workflows). This could be a hybrid with generated data, ie. drawings and reports, placed in structured file storage rather than git.

    Is there any serious prospect of IFC models being stored in server-side graph databases with client API access? This seems unlikely technically, and it has downsides in terms of potential for lock-in and rent-seeking.

  9. A by aothms on 7 Dec 2024 # +1 votes

    Is there any serious prospect of IFC models being stored in server-side graph databases with client API access

    I don't know. I have some clients that use Neo4j, but I don't think it's full-fledged IFC. @krande made quite some progress with https://github.com/Krande/ifcdb And we also had some other people outlining the options: https://github.com/IfcOpenShell/IfcOpenShell/issues/4276#issuecomment-1927008332 Years back I heard good things about the scalability of https://github.com/dgraph-io/dgraph but it's unverified.

    These kind of efforts are fairly diffuse and low energy in our community, I'd rather aim a bit more ambitious and allow for graph db tech to catch up to our data volumes than aim for something that's mainstream now, but doesn't really inspire end-users or developers. I'm not too worried about lock-in if it is IFC.

    Git is indeed a really nice middle-ground. For the non-semantic or non-text data you could also use sth like LFS. But I'd be a little bit worried about non-natively authored data and the scalability on huge data sets.

    Even it we opt for a file storage backed system there is a lot of potential in the tooling we have around IFC, such as IfcTester or 4D that can see more adoption if we're able to offer a more integrated workflow.

    I guess we also shouldn't make one choice, but rather standardize on the interfaces, build something modular and extensible, but it sound rather abstract in this case.

  10. M by mko on 2 Jan 2025, edited 2 Jan 2025 # +4 votes

    Hi all,

    Regarding Forgejo, I'm pleased to announce a new version of Git/AEC with a docker image ready to go if you want to give it a try :

    https://gitaec.org

    Let me know if something not working properly. I will soon bake some new IfcOpenShell worflow examples.

    IFC5 and git-based design-platforms could be the perfect match, I guess... Exciting times !

    Cheers,

    Milovann

  11. T by theoryshaw on 6 Jan 2025 # +7 votes

    @mko cool! Seems like there could be some excited synergies here!

    Sorry the delay, but wanted to wait until the holidays were over, before initiating the following campaigns.

    OSArch's Git Platform: Transferring the Instance

    go here to help fund: https://opencollective.com/osarch/projects/hub_osarch_migration

    This funding campaign will cover costs associated with transferring and migrating the existing hub.openingdesign.com instance to hub.osarch.org, where it will be managed under OSArch's governance.

    Meissa, a third-party consultancy, has developed a proposal to ensure a smooth migration to OSArch's platform.

    Migration Steps

    1. DNS & Certificate Update: Configure the OSArch domain name and update SSL certificates.

    2. Server Configuration: Update the HTTP server to recognize the new domain.

    3. Customization: Adjust branding, including text and logos, to reflect OSArch’s identity.

    Proposed Fee

    • Migration Services | Fixed price for DNS, certificates, and branding |

      • €1,600

    • Support Services after Migration | Hourly rate for 2nd & 3rd level support (as needed) |

      • €80/hour

    Note: Meissa will donate 10% of the project’s turnover to the open-source Forgejo project at codeberg.org.

    Funding Matching

    In line with OSArch’s funding campaign, all contributions to this project will be matched by OSArch's general funds.

    OSArch Git Platform: Monthly Expenses

    go here to help fund: https://opencollective.com/osarch/projects/hub_osarch_monthly_expenses

    This funding campaign will cover the ongoing monthly and periodical maintenance costs associated with this platform.

    Current and Projected Costs:

    • Monthly costs: Currently around $75/month, which may fluctuate based on the number of users and storage requirements.

    • Maintenance: While the exact cost is still to be determined, a placeholder estimate of $3,000/year has been set for the time being.

    Any surplus funds from this campaign will be allocated toward funding the development of additional, AEC-specific functionality on hub.OSArch.com. A few potential tools for future development are outlined below.

    Current and Proposed Functionality

    The platform will enable the OSArch community to effectively manage and share BIM content, with a focus on open collaboration via NativeIFC. Key benefits include:

    • Centralized Hosting for IFC Content Libraries

      • A space to host, maintain, and share IFC libraries for easy community access and contribution.

    • Code Sharing and Collaboration

      • A repository for code snippets, tools, and workflows shared within the community.

    • Support for Company Projects

      • A platform where companies can host both public and private projects, encouraging open-source adoption.

    • Tool Development

      • A space for collaborative improvement of community-driven projects like IfcMerge.

    • Integration of IFC Workflows

      • Over time, the platform could include advanced features such as an embedded IFC viewer and tools for IFC diffing and merging (demo).
  1. Page 1
  2. 2

Login or Register to reply.