カタパルト開発者によるプレビュー - SDK（ソフトウェア開発キット）の拡張

本記事は以下を和訳したものです。
nemflash.io

・・・

カタパルト開発者によるプレビュー - SDK（ソフトウェア開発キット）の拡張
ジュリアン・2018年4月18日

新しいソフトウェア開発キット（以後SDK)には主に、カタパルト特有のAPIにおいて主要でない部分を削り汎用性のあるものにするという1つの目標があります。プログラミング言語間で同じ構成、及び構造を共有し、NEM上にプロジェクトを構築しようとする人々が同じ方法で作動させることができるようにします。

アポスティーユ、投票モジュール、ネームスペースのエイリアスシステムなどのプロジェクトは、再利用可能なNEMの上に構築されたアプリケーションです。 しかし、技術的な基盤においてはこれらアプリケーションの再利用可能性を制限していました。

現在、これらの実装は、プラットフォーム間における互換性のために標準化された仕様に必ずしも準拠していないプロジェクト、またはプログラムの集合体であるライブラリに付属しています。NEM2-SDKとライブラリはこれを解決しようとしています。

情報発信元：medium

NEM2-SDKおよびライブラリ
重厚でフル装備のSDKを作る事とは別に、堅牢で軽量なSDKも開発しています。 このSDKのおかげで、NEM2-SDK上に各標準ごとに異なるライブラリを開発することができ、NEMアプリケーションの高度かつ高速化が可能になりました。

開発者は単独で機能するスタンドアローンのライブラリを作成してNEMに機能を追加することもできます。 しかし、一般化し受け入れられるライブラリになるためには、nemにおける改善提案（NIP）として提案されるべきです。

NIPリポジトリがあるのは、新しいライブラリをNEM開発者が見直し、テストし、共有できるようにするためです。非NIPライブラリと比較してより高度なものの導入を可能にします。

NEMブロックチェーンを使用したユースケースの設計を持つ人は、取り組んでいるライブラリにおいてさらに良い定義に到達するためにコミュニティと議論するプラットフォームを持つようになりました。

ライブラリを作成するにはNIPを作成する必要があるのですか？
いいえ、不要です。実際、NEMブロックチェーンとそれを使用するさまざまなプロジェクトを改善するライブラリを構築するまでは、NIPを提出しないことをお勧めします。ライブラリは複数回変更できるため、開発者は実験や学習に多くの時間を費やして、後で仕様を作成するべきでます。

私たちはアイデアを共有し、NEMプロジェクトのチャンネル（https://t.me/nemprojects）でディスカッションすることをお勧めします。

アポスティーユにおける実例
アポスティーユは長い間NEMに実装されており、当初からNanoWalletで入手可能です。別のプラットフォームでアポスティーユ機能を使用する場合はどうか？ それは容易な事ではありません。

NEMブロックチェーンを読み書きする特定の方法に私たちが賛同することが、アポスティーユの本質になります。私たちががどのようにNEMを読み書きするかによって、アポスティーユの妥当性が決まります。

このため、NIPリポジトリに承認された共有仕様が必要です。 開発者は仕様を議論し、改善し、さらなる開発への取り組みの標準となることを確実にすることができます。

アポスティーユのNIS1実装の最初の概念設計はgimboyaによって提案されましたが、現在はカタパルトでアップデートされています：https://github.com/gimyboya/Apostil-library

ぜひ、改善提案を提出し、NEMの機能を拡張するためのライブラリの構築をしてください。

この投稿の公式なディスカッションはフォーラムのスレッドで確認することができます。

・・・
以下原文
・・・

Catapult Developers Preview — Extending the SDK
BY JULIAN · APRIL 18, 2018

The new SDKs mainly have one goal: to abstract the Catapult specific API details. Sharing the same architecture and structure between languages allows for everyone who builds a project on top of NEM to work in a similar way.

Projects such as Apostille, the voting module and the alias system are applications built on top of NEM that should be reusable. However, the technological infrastructure limited the reusability of these applications.

Currently, these implementations are usually attached to other projects or libraries that don’t necessarily follow standardised specifications for cross-platform compatibility. This is what the NEM2-SDK and Libraries aim to solve.

First appeared on medium

NEM2-SDK and Libraries
Aside from creating a heavy and full-featured SDK, we are also developing a robust and lightweight SDK. Thanks to this SDK, different libraries can be developed for each standard on top of NEM2-SDK allowing higher and faster growth for NEM applications.

Developers could opt to create a standalone library to add more features to NEM. However, to become an accepted library, it should be proposed as a NIP.

The reason behind the NIP Repository is to ensure the new library to be reviewed, tested and shared among NEM developers. It allows a higher adoption compared to non-NIP libraries.

Anyone with a design for a particular use case using the NEM blockchain now has a platform to discuss with the community in order to reach better definitions for the supported libraries.

Do I need to create a NIP to create a library?
No, you don’t. In fact, we suggest to not submit a NIP until you build a library that improves the NEM blockchain and the different projects that use it. Since the library can be changed multiple times, developers should spend more time experimenting and learning, creating a specification later on.

We would like to encourage you to share your ideas and generate discussion on the NEM Projects channel: https://t.me/nemprojects

Apostille, a real example
Apostille has been in NEM for a long time, being available in NanoWallet since its beginning. What happens if another platform wants to use the Apostille feature? It is not as easy as it should be.

The nature of Apostille is that we agree in a specific way to write and read in NEM Blockchain. The way we write and how we read from NEM determines the validity of the Apostille.

For this reason, we require an approved and shared specification in the NIP repository. Developers can discuss specifications, improve it, and make sure it becomes a supported standard for further developments.

A first draft of Apostille’s implementation on NIS1 was proposed by gimboya, although it is now being updated to Catapult: https://github.com/gimyboya/Apostil-library

Feel free to submit your improvement proposals and start building libraries that can help extend NEM’s capabilities.

You can find this post’s official discussion on the forum thread.