Hi, The separation into 3 layers sounds like a good approach. The current stub code contains mainly attribute metadata definition and attributes list parsing. In addition, there is a minimal storage layer, mainly for next hop group and object IDs.
Adding a full storage layer will make the code much more useful, by allowing test application to perform set and then get for objects/attributes. Looking forward to seeing the code. Thanks, Itai -----Original Message----- From: Soramichi AKIYAMA [mailto:akiyama.sorami...@lab.ntt.co.jp] Sent: Wednesday, June 17, 2015 8:41 AM To: Itai Baz Cc: opencompute-networking@lists.opencompute.org Subject: Re: [Opencompute-networking] SAI stub implementation Hello, as I emailed, we released a small SAI implementation recently. https://github.com/osrg/libsai Since a future plan in sai/stub/README.md is to "have a storage layer to store the created object" and our project already includes some storage layer codes, we are thinking about - Seperating our codes into three parts: stub, storage layer, and data plane - Contributing the separated storage layer codes to sai/stub We would like to know what the OCP networking community thinks about this idea. Best regards, Soramichi AKIYAMA Software Innovation Center, Nippon Telegraph and Telephone (NTT), Japan akiyama.sorami...@lab.ntt.co.jp On Thu, 4 Jun 2015 17:12:09 +0000 Itai Baz <it...@mellanox.com> wrote: > Hi, > I submitted a stub implementation for SAI : > It performs extensive parameter checking, and prints verbose output to syslog. > Applications can link with it, and have SAI library functionality. > Full information is in readme.md > > https://github.com/opencomputeproject/OCP-Networking-Project-Community > -Contributions/pull/98 > > Itai _______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
