ভাষার স্পেসিফিকেশন

এই পৃষ্ঠায় ISO/IEC 14977 এক্সটেন্ডেড ব্যাকাস-নাউর ফর্ম (EBNF) এবং প্রোটোবাফ ব্যবহার করে ভেহিকেল সার্ভিস ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ (VSIDL) নির্দিষ্ট করা হয়েছে। এই পৃষ্ঠাটি ভাষাটির কনটেক্সট-ফ্রি ব্যাকরণ এবং ভাষা উপাদানগুলোর অর্থের উপর আলোকপাত করে।

ভাষার শ্রেণিবিন্যাস

মেটা অবজেক্ট ফ্যাসিলিটি (MOF) অনুসারে, VSIDL কম্পাইলার (VSIDLC) চিত্র ১-এ দেখানো ভাষাগুলো ব্যবহার করে:

চিত্র ১. ভিএসআইডিএলসি ভাষাসমূহ।

VSIDLC প্রধানত প্রোটোকল বাফার (প্রোটোবাফ) ভাষার উপর ভিত্তি করে তৈরি। পাবলিশ-সাবস্ক্রাইব এবং রিমোট প্রসিডিউর কল (RPC) ব্যবহার করে আদান-প্রদান করা ডেটা টাইপগুলো নির্দিষ্ট করার জন্য প্রোটোবাফ ব্যবহৃত হয়। প্রযুক্তিগত দৃষ্টিকোণ থেকে, VSIDL মডেলগুলো হলো টেক্সটপ্রোটো ফাইল, যেখানে VSIDL-এর সিনট্যাক্স একটি প্রোটোবাফ ফাইলে ( syntax.proto ) সংজ্ঞায়িত করা থাকে। ডেটা টাইপ নির্দিষ্ট করার জন্য ব্যবহৃত প্রোটোবাফ ফাইল এবং VSIDL মডেল উভয়ই রাস্ট কোড তৈরি করতে ব্যবহৃত হয়। তৈরি করা কোডটিতে প্রধানত স্ট্রাক্ট (struct) থাকে, যা আদান-প্রদান করা মেসেজগুলোর জন্য ডেটা স্ট্রাকচার বাস্তবায়ন করে, এবং রাস্ট ফাংশন থাকে, যা স্বয়ংক্রিয়ভাবে সার্ভিস ইউনিটগুলোকে কল না করেই রাস্টে সার্ভিস ইউনিট তৈরির কাজ করে। এই তৈরি করা রাস্ট কোডের সাথে কাস্টম রাস্ট কোডও থাকে, যা সার্ভিস ইউনিট ইনস্ট্যানশিয়েট করতে এবং অ্যাপ্লিকেশনটির বিজনেস লজিক বাস্তবায়ন করতে এই তৈরি করা কোডটি ব্যবহার করে।

বিমূর্ত সিনট্যাক্স

চিত্র ২-এ VSIDL-এর মূল বার্তা প্রকারগুলি দেখানো হয়েছে:

চিত্র ২. VSIDL-এর মূল বার্তা প্রকারসমূহ।

VSIDL এন্ট্রি

এই অংশে VSIDL এন্ট্রি মেসেজ টাইপ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

start VsidlEntry =
  "package" , ":" , String , ";" ,
  { "service_bundle" , ServiceBundle } ,
  { "extension" , ":" , Any } ,
  { "some_ip_mapping" , ":" , SomeIpMapping } ,
  { "vhal_mapping" , ":" , VhalMapping }
;

প্রোটো সংজ্ঞা

// The root message for VSIDL files
message VsidlEntry {
  // Required. Package name for entities mentioned in the file.
  string package = 1;
  // Enables custom extensions beyond the standard VSIDL model.
  repeated google.protobuf.Any extension = 3;

  // SOMEIP mapping rules
  repeated sdv.someip.v1.SomeIpMapping some_ip_mapping = 4;
  // VHAL mapping rules
  repeated VhalMapping vhal_mapping = 5;
  // List of SDV service bundles defined in the file.
  repeated ServiceBundle service_bundle = 6;
}

ব্যবহারের উদাহরণ

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "Manager"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    topic: "front-right"
    capacity: 10
  }
}

ব্যাখ্যা

VsidlEntry মেসেজটি VSIDL ফাইলের (যার এক্সটেনশন .vsidl ) মূল ধারক হিসেবে কাজ করে। এই মেসেজটি সমস্ত সংজ্ঞা এবং কনফিগারেশনকে একটিমাত্র VSIDL ফাইলে আবদ্ধ করে। VsidlEntry হলো সর্বোচ্চ স্তরের উপাদান যা অন্য সবকিছুকে সংযুক্ত করে।

উদ্দেশ্য:

• একটি VSIDL ফাইলের সামগ্রিক কাঠামো নির্ধারণ করে।
• ফাইলের অন্তর্গত সমস্ত এনটিটির জন্য প্যাকেজ নেমস্পেস নির্দিষ্ট করে।
• এতে সার্ভিস বান্ডেল সংজ্ঞাগুলোর একটি সংগ্রহ রয়েছে।
• VSIDL মডেলে কাস্টম এক্সটেনশন যুক্ত করার সুযোগ দেয়।
• SOME/IP এবং VHAL-এর জন্য ম্যাপিং নিয়মাবলী অন্তর্ভুক্ত।

সীমাবদ্ধতা

• প্যাকেজের নাম (E211): প্যাকেজের নাম ১২৭ অক্ষরের বেশি হবে না।
• ড্যাংলিং ফাইল (E10B): একটি ক্যাটালগের সমস্ত ফাইল অবশ্যই একটি Android.bp ফাইলগ্রুপে রেফারেন্স করা থাকতে হবে।

পরিষেবা বান্ডেল

এই অংশে সার্ভিস বান্ডেল মেসেজ টাইপ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

ServiceBundle = "{" , { ServiceBundleElement } , "}" ;

ServiceBundleElement =
  "name" , ":" , String |
  "publisher" , Publisher |
  "subscriber" , Subscriber |
  "server" , Server |
  "client" , Client |
  "extension" , ":" , Any |
  "diagnostics_declaration" , DiagnosticsDeclaration |
  "build_cfg" , BuildConfiguration |
  "register_reflection_metadata" , Boolean
;

প্রোটো সংজ্ঞা

// Defines an SDV service
message ServiceBundle {
  // Required. Name of the service bundle (without the package name).
  string name = 1;
  // List of publications the service bundle provides.
  repeated Publisher publisher = 2;
  // List of publications a service bundle subscribes to.
  repeated Subscriber subscriber = 3;
  // RPC services offered by a service bundle.
  repeated Server server = 4;
  // RPC services consumed by a service bundle.
  repeated Client client = 5;
  // Enables custom extensions beyond the standard VSIDL model.
  repeated google.protobuf.Any extension = 7;

  // Diagnostics declarations
  sdv.diagnostics.v1.DiagnosticsDeclaration diagnostics_declaration = 8;

  // Build Configuration
  optional BuildConfiguration build_cfg = 9;

  // Register metadata for service units provided by this service bundle.
  // Setting this to true will increase the memory footprint
  // and network load significantly.
  bool register_reflection_metadata = 10;
}

ব্যবহারের উদাহরণ

service_bundle {
    name: "SeatController"

    publisher {
      message: "SeatHeating"
      topic: "driver-seat"
      capacity: 10
    }
}

ব্যাখ্যা

একটি সার্ভিস বান্ডেল সম্পর্কিত সার্ভিস, পাবলিশার, সাবস্ক্রাইবার, আরপিসি সার্ভার এবং আরপিসি ক্লায়েন্টদের একটি যৌক্তিক গোষ্ঠীকে সংজ্ঞায়িত করে। একটি সার্ভিস বান্ডেল নির্দিষ্ট কিছু কার্যকারিতা এবং তাদের পারস্পরিক ক্রিয়াকলাপের জন্য একটি ধারক হিসেবে কাজ করে।

সীমাবদ্ধতা

• বান্ডেলের নামের আবশ্যকতা (E209, E20A, E20B, E20C):
  • একটি সার্ভিস বান্ডেলের অবশ্যই একটি নাম থাকতে হবে।
  • নামটি অবশ্যই একটি বৈধ ইউনিকোড শনাক্তকারী প্রারম্ভিক অক্ষর (সাধারণত একটি অক্ষর) দিয়ে শুরু হতে হবে।
  • নামের পরবর্তী অক্ষরগুলো অবশ্যই বৈধ ইউনিকোড আইডেন্টিফায়ার কন্টিনিউয়েশন ক্যারেক্টার (সাধারণত বর্ণ বা সংখ্যা) হতে হবে।
  • নামটি রাস্ট, জাভা বা সি++ এর কোনো সংরক্ষিত কীওয়ার্ড হতে পারবে না।
• গ্লোবাল বান্ডেল অনন্যতা (E309): প্রতিটি সার্ভিস বান্ডেলের একটি অনন্য সম্পূর্ণ যোগ্য নাম থাকতে হবে (এর প্যাকেজ এবং নামের উপর ভিত্তি করে)।
• অভ্যন্তরীণ অনন্যতা (E100, E300, E302, E303, E308):
  • একটি একক সার্ভিস বান্ডেলের মধ্যে, প্রতিটি RPC সার্ভিস সর্বাধিক একটি সার্ভার ডেফিনিশন দ্বারা পরিবেশিত হতে পারে।
  • একটি একক সার্ভিস বান্ডেলের মধ্যে, প্রতিটি MULTI_PUB পাবলিকেশন টাইপ সর্বাধিক একটি পাবলিশার ডেফিনিশন দ্বারা পাবলিশ করা যেতে পারে।
  • একটি একক সার্ভিস বান্ডেলের মধ্যে, ব্যবহারকারী-সংজ্ঞায়িত সকল সার্ভিস ইউনিটের নাম (পাবলিশার বা সার্ভারের জন্য) অবশ্যই অনন্য হতে হবে।
  • একটি একক সার্ভিস বান্ডেলের মধ্যে, সমস্ত সার্ভিস ইউনিটের নাম (সেগুলো ব্যবহারকারী-নির্ধারিত হোক বা স্বয়ংক্রিয়ভাবে তৈরি হোক) অবশ্যই অনন্য হতে হবে।
• বিল্ড টার্গেট নামকরণের নিয়মাবলী (E205, E206, E207, E208): যদি একটি কাস্টম বিল্ড টার্গেট নাম ( build_cfg.target_name ) প্রদান করা হয়, তবে এটিকে অবশ্যই স্নেক কেস ফরম্যাট মেনে চলতে হবে (ছোট হাতের অক্ষর, সংখ্যা এবং একক আন্ডারস্কোর, যা আন্ডারস্কোর দিয়ে শুরু বা শেষ হবে না)।
• বিল্ড টার্গেট নামের অনন্যতা (E301): ব্যবহারকারী-সংজ্ঞায়িত বিল্ড টার্গেট নাম অন্য সার্ভিস বান্ডেলের জন্য স্বয়ংক্রিয়ভাবে তৈরি কোনো টার্গেট নামের সাথে সাংঘর্ষিক হওয়া যাবে না।

প্রকাশক

এই অংশে পাবলিশার মেসেজ টাইপ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

Publisher = "{" , { PublisherElement } , "}" ;

PublisherElement =
  "message" , ":" , String |
  "topic" , ":" , String |
  "capacity" , ":" , Integer |
  "service_unit_name" , ":" , String
;

প্রোটো সংজ্ঞা

// Represents a publisher within a service bundle.
message Publisher {
  // Name of the service unit. Name may only use characters from [a-z0-9\-]+,
  // must start with [a-z], may not end with a hyphen,
  // and may not contain consecutive hyphens.
  string service_unit_name = 3;
  // Required. The type of data being published.
  string message = 4;
  // Required. The number of messages a publication queue can hold.
  // Must be an even number >= 2.
  int64 capacity = 6;
  // Required. Unique identifier for the publication topic.
  // Must be in lowercase dash-case.
  repeated string topic = 7;
}

ব্যবহারের উদাহরণ

publisher {
  message: "SeatHeating"
  topic: "driver-heating"
  capacity: 10
}

ব্যাখ্যা

Publisher মেসেজ টাইপটি ServiceBundle দ্বারা প্রদত্ত একটি ডেটা সোর্সকে সংজ্ঞায়িত করে। এই মেসেজ টাইপটি প্রকাশিতব্য ডেটার ধরন এবং সেই ডেটার নির্দিষ্ট টপিক ও ধারণক্ষমতা উল্লেখ করে।

বিষয়সমূহ

প্রতিটি Publisher ইনস্ট্যান্সে একটি message ফিল্ড থাকে যা প্রকাশিত হতে থাকা প্রোটো মেসেজটিকে নির্দেশ করে। এতে অবশ্যই একটি টপিক ( topic দ্বারা উপস্থাপিত) এবং একটি ক্যাপাসিটি ( capacity দ্বারা উপস্থাপিত) নির্দিষ্ট করতে হবে।

• বিষয়: প্রকাশনার বিষয়ের জন্য একটি অনন্য শনাক্তকারী। এটি অবশ্যই ছোট হাতের অক্ষরে এবং ড্যাশ-সহ হতে হবে (উদাহরণস্বরূপ, my-topic )।
• ধারণক্ষমতা: কিউ-এর আকার নির্দিষ্ট করে, অর্থাৎ অপঠিত বার্তা বাতিল করার আগে কিউ-টি কতগুলো বার্তা ধারণ করতে পারে। এটি অবশ্যই ২ বা তার বেশি একটি জোড় সংখ্যা হতে হবে।

ব্যবহারকারী-সংজ্ঞায়িত নাম

পাবলিশাররা ব্যবহারকারী-সংজ্ঞায়িত সার্ভিস ইউনিট নাম ব্যবহার করতে পারেন, যা স্বয়ংক্রিয়ভাবে নির্বাচিত সার্ভিস ইউনিট নামগুলোকে বাতিল করে দেয়। এই সুবিধাটি ছোট নাম বেছে নেওয়ার সুযোগ করে দেয়। যদি কোনো পাবলিশার ব্যবহারকারী-সংজ্ঞায়িত সার্ভিস ইউনিট নাম ব্যবহার করে, তবে সে কেবল একটিমাত্র ইনস্ট্যান্স ব্যবহার করতে পারে, যাতে সার্ভিস ইউনিট নামটি একটিমাত্র ইনস্ট্যান্সের জন্য অনন্যভাবে নির্ধারিত হয়।

# VALID: A publisher assigns a user-defined name to a single instance
publisher {
  message: "SeatHeating"
  topic: "seat-heating-status"
  service_unit_name: "heating-is-off"
}

# ERROR: user-defined names are only allowed if there's only a single instance
publisher {
  message: "SeatHeating"
  topic: "seat-heating-status"
  service_unit_name: "heating-status"
}

সীমাবদ্ধতা

• পাবলিশার প্লেসমেন্ট (E300): একই MULTI_PUB টাইপের পাবলিশারদের অবশ্যই আলাদা সার্ভিস বান্ডেলে সংজ্ঞায়িত করতে হবে।
• স্থানীয় নামের অনন্যতা (E302): যেকোনো একটি সার্ভিস বান্ডেলের মধ্যে, সকল পাবলিশারের অবশ্যই অনন্য ব্যবহারকারী-সংজ্ঞায়িত সার্ভিস ইউনিট নাম থাকতে হবে।
• বৈশ্বিক নামের অনন্যতা (E304): একই প্রকাশনা প্রকারের প্রকাশকদের অবশ্যই সমস্ত পরিষেবা বান্ডেল জুড়ে বিশ্বব্যাপী অনন্য ব্যবহারকারী-সংজ্ঞায়িত পরিষেবা ইউনিটের নাম থাকতে হবে।
• একক চ্যানেলের নামকরণ (E306): ব্যবহারকারী-সংজ্ঞায়িত পরিষেবা ইউনিটের নাম শুধুমাত্র সেইসব পাবলিশারকে বরাদ্দ করা যেতে পারে যারা ঠিক একটি ইনস্ট্যান্স পরিচালনা করে।
• একক প্রকাশক সীমা (E307): SINGLE_PUB হিসেবে চিহ্নিত একটি প্রোটোবাফ বার্তা সমগ্র সিস্টেম জুড়ে শুধুমাত্র একজন প্রকাশক দ্বারা প্রকাশিত হতে পারে।
• সার্ভিস ইউনিটের নামের অনন্যতা (E308): সমস্ত সার্ভিস ইউনিটের নাম (সেটি স্বয়ংক্রিয়ভাবে তৈরি হোক বা ব্যবহারকারী-সংজ্ঞায়িত হোক) তাদের সার্ভিস বান্ডেলের মধ্যে অবশ্যই অনন্য হতে হবে; স্বয়ংক্রিয়ভাবে তৈরি নামের সাথে দ্বন্দ্ব নিরসনের জন্য ব্যবহারকারী-সংজ্ঞায়িত নাম ব্যবহার করা উচিত।
• ভ্যারিয়েন্ট নির্দিষ্টকরণের আবশ্যকতা (E501): যখন কোনো প্রকাশক একাধিক ভ্যারিয়েন্টযুক্ত কোনো টাইপের জন্য ব্যবহারকারী-সংজ্ঞায়িত নাম ব্যবহার করে, তখন তাকে অবশ্যই প্রকাশিত ভ্যারিয়েন্টটি সুস্পষ্টভাবে উল্লেখ করতে হবে।
• সাবস্ক্রাইবারদের জন্য পাবলিশারের অস্তিত্ব (E504): প্রতিটি সংজ্ঞায়িত সাবস্ক্রাইবারের জন্য নির্দিষ্ট টাইপ এবং ভ্যারিয়েন্টের জন্য অন্তত একটি সংশ্লিষ্ট পাবলিশার প্রয়োজন।
• বৈধ পাবলিশার টাইপ (E601): একজন পাবলিশারকে অবশ্যই এমন একটি টাইপ রেফারেন্স করতে হবে যা একটি বিদ্যমান প্রোটোবাফ মেসেজের সাথে সঙ্গতিপূর্ণ।
• প্রকাশনা টীকা আবশ্যকতা (E602): কোনো প্রকাশক কর্তৃক উল্লিখিত প্রোটোবাফ বার্তা প্রকারে অবশ্যই SdvPublication টীকাটি অন্তর্ভুক্ত থাকতে হবে।
• বৈধ ভ্যারিয়েন্ট ব্যবহার (E606): যদি কোনো প্রকাশক একটি ভ্যারিয়েন্ট (ইনস্ট্যান্স) নির্দিষ্ট করে, তবে সেই ভ্যারিয়েন্টটি অবশ্যই প্রোটোবাফে প্রকাশনা প্রকারের জন্য সংজ্ঞায়িত instances_enum মধ্যে বিদ্যমান থাকতে হবে।
• ভ্যারিয়েন্ট নির্দিষ্টকরণের শর্ত (E607): একজন প্রকাশক শুধুমাত্র তখনই একটি সুস্পষ্ট ভ্যারিয়েন্ট (ইনস্ট্যান্স) নির্দিষ্ট করতে পারেন, যদি প্রকাশনার ধরণটি প্রোটোবাফে একটি instances_enum সংজ্ঞায়িত করে।
• টপিকের নামকরণ (E20D, E20F): টপিক অবশ্যই ছোট হাতের অক্ষরে (ড্যাশ-কেস) হতে হবে এবং ১২৭ অক্ষরের বেশি হবে না।
• টপিকের অনন্যতা (E314): টপিকগুলো অবশ্যই সকল প্রকাশকের মধ্যে বিশ্বব্যাপী অনন্য হতে হবে।
• ধারণক্ষমতার প্রয়োজনীয়তা (E406, E407): ধারণক্ষমতা বাধ্যতামূলক এবং অবশ্যই একটি জোড় সংখ্যা হতে হবে, যা ২ বা তার বেশি।

গ্রাহক

এই অংশে সাবস্ক্রাইবার বার্তার ধরণ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

Subscriber = "{" , { SubscriberElement } , "}" ;

SubscriberElement =
  "message" , ":" , String |
  "topic" , ":" , String
;

প্রোটো সংজ্ঞা

// Represents a subscriber within a service bundle.
message Subscriber {
  // Required. The type of data being subscribed to.
  string message = 4;
  // Required. Specific topic(s) of the message to subscribe to.
  // Must match the publisher's topic.
  repeated string topic = 6;
}

ব্যবহারের উদাহরণ

subscriber {
  message: "SeatHeating"
  topic: "driver-seat"
}

ব্যাখ্যা

Subscriber মেসেজটি ServiceBundle দ্বারা প্রদত্ত একটি পাবলিকেশন রিসিভারকে সংজ্ঞায়িত করে। এই মেসেজটি কোন ধরনের ডেটা সাবস্ক্রাইব করা হচ্ছে এবং সেই পাবলিকেশনের নির্দিষ্ট টপিকগুলো উল্লেখ করে। যদি কোনো টপিকের জন্য একাধিক পাবলিশার থাকে, তবে সাবস্ক্রাইবার তাদের সকলের দ্বারা প্রকাশিত মেসেজগুলো গ্রহণ করে।

সীমাবদ্ধতা

• প্রকাশকের অস্তিত্ব (E504): প্রতিটি সংজ্ঞায়িত গ্রাহকের জন্য, অন্তত একজন সংশ্লিষ্ট প্রকাশক অবশ্যই থাকতে হবে যিনি নির্দিষ্ট প্রকাশনার ধরণ এবং রূপ প্রকাশ করেন।
• বৈধ সাবস্ক্রিপশন টাইপ (E608): একজন সাবস্ক্রাইবারকে অবশ্যই এমন একটি টাইপ রেফারেন্স করতে হবে যা SdvPublication অ্যানোটেশন দ্বারা সংজ্ঞায়িত একটি বিদ্যমান প্রোটোবাফ মেসেজের সাথে সঙ্গতিপূর্ণ।
• বৈধ ভ্যারিয়েন্ট সাবস্ক্রিপশন (E609): যদি কোনো সাবস্ক্রাইবার একটি ভ্যারিয়েন্ট (ইনস্ট্যান্স) নির্দিষ্ট করে, তবে সেই ভ্যারিয়েন্টটি অবশ্যই সংশ্লিষ্ট প্রোটোবাফ পাবলিকেশন টাইপের instances_enum এর মধ্যে সংজ্ঞায়িত একটি বৈধ মান হতে হবে।
• বিষয় আবশ্যিক (E408): গ্রাহকদের জন্য বিষয়টি আবশ্যিক।
• টপিক পুনঃঘোষণা (E311): একই সার্ভিস বান্ডেলে সাবস্ক্রাইবার টপিক পুনঃঘোষণা করা উচিত নয়।

আরপিসি সার্ভার

এই অংশে আরপিসি সার্ভার মেসেজ টাইপ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

Server = "{" , { ServerElement } , "}" ;

ServerElement =
  "service" , ":" , String |
  "channel" , ":" , String |
  "service_unit_name" , ":" , String
;

প্রোটো সংজ্ঞা

// Represents an RPC server within a service bundle.
message Server {
  // Deprecated. Name of the service unit.
  string service_unit_name = 3 [ deprecated = true ];
  // Required. Name of the RPC service.
  string service = 4;
  // Required. Name of the RPC channel.
  // Must be in lowercase dash-case.
  string channel = 5;
}

ব্যবহারের উদাহরণ

server {
  service: "SetTemperature"
  channel: "temp-setter"
}

ব্যাখ্যা

Server মেসেজটি ServiceBundle দ্বারা প্রদত্ত একটি আরপিসি সার্ভারকে সংজ্ঞায়িত করে। এই মেসেজটি সার্ভার দ্বারা বাস্তবায়িত সার্ভিস এবং আরপিসি চ্যানেল নির্দিষ্ট করে।

একটি RPC সার্ভার এমন কিছু মেথড প্রকাশ করে যা ক্লায়েন্টরা দূর থেকে কল করতে পারে। ' service ফিল্ডটি সেই RPC সার্ভিসের নাম নির্দিষ্ট করে যা সার্ভারটি ইমপ্লিমেন্ট করে। এই সার্ভিসটি একটি প্রোটো ফাইলে সংজ্ঞায়িত করা হয় এবং কাস্টম রাস্ট কোডে ইমপ্লিমেন্ট করা হয়। প্রোটোবাফ সার্ভিস ডেফিনিশনে সংজ্ঞায়িত অনুযায়ী, RPC সার্ভিসগুলোতে ইউনারি, ক্লায়েন্ট-স্ট্রিমিং এবং সার্ভার-স্ট্রিমিং মেথড অন্তর্ভুক্ত থাকতে পারে। channel ফিল্ডটি কমিউনিকেশন এন্ডপয়েন্ট নির্ধারণ করে এবং এটি বাধ্যতামূলক (E409)।

সীমাবদ্ধতা

• পরিষেবা সংজ্ঞা (E603): একটি RPC সার্ভারকে অবশ্যই এমন একটি service মান নির্দিষ্ট করতে হবে যা একটি বিদ্যমান প্রোটোবাফ RPC service মানের সাথে সঙ্গতিপূর্ণ।
• প্রতি পরিষেবাতে সার্ভারের সীমা (E100): একটি একক পরিষেবা বান্ডেলের মধ্যে, একটি নির্দিষ্ট RPC service সর্বাধিক একটি সার্ভার সংজ্ঞা দ্বারা পরিবেশিত হতে পারে।
• চ্যানেলের নামকরণ (E20E): RPC চ্যানেল অবশ্যই ছোট হাতের ড্যাশ-কেস অক্ষরে হতে হবে।
• চ্যানেল বাধ্যতামূলক (E409): আরপিসি চ্যানেল বাধ্যতামূলক।
• চ্যানেলের অনন্যতা (E40B): RPC চ্যানেল অবশ্যই শুধুমাত্র একটি পরিষেবা দ্বারা ব্যবহৃত হতে হবে।

আরপিসি ক্লায়েন্ট

এই অংশে আরপিসি ক্লায়েন্ট মেসেজ টাইপ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

Client = "{" , { ClientElement } , "}" ;

ClientElement =
  "service" , ":" , String |
  "channel" , ":" , String
;

প্রোটো সংজ্ঞা

// Represents an RPC client within a service bundle.
message Client {
  // Required. Name of the RPC service.
  string service = 2;
  // Required. Name of the RPC channel.
  // Must match the server's channel and be in lowercase dash-case.
  string channel = 3;
}

ব্যবহারের উদাহরণ

client {
  service: "SetTemperature"
  channel: "temp-setter"
}

ব্যাখ্যা

client একটি RPC ক্লায়েন্টকে সংজ্ঞায়িত করে যা ServiceBundle ব্যবহার করে। client নির্দিষ্ট করে দেয় যে ক্লায়েন্টটি কোন সার্ভিসের সাথে ইন্টারঅ্যাক্ট করবে এবং কোন চ্যানেলে সংযোগ স্থাপন করবে। সার্ভিসের সংজ্ঞার উপর নির্ভর করে, ক্লায়েন্টটি ইউনিটারি, ক্লায়েন্ট-স্ট্রিমিং এবং সার্ভার-স্ট্রিমিং মেথড ব্যবহার করে ইন্টারঅ্যাক্ট করতে পারে।

সীমাবদ্ধতা

• সার্ভিস সংজ্ঞা (E60A): একটি RPC ক্লায়েন্টকে অবশ্যই এমন একটি service নির্দিষ্ট করতে হবে যা একটি বিদ্যমান প্রোটোবাফ service সংজ্ঞার সাথে সঙ্গতিপূর্ণ।
• অনন্য পরিষেবা উৎস (E60B): একটি RPC ক্লায়েন্টের service দ্বারা ব্যবহৃত প্রোটোবাফ service সংজ্ঞাটি অবশ্যই সমস্ত প্রোটোবাফ ফাইল জুড়ে অনন্যভাবে সংজ্ঞায়িত হতে হবে (একাধিকবার সংজ্ঞায়িত করা যাবে না)।
• চ্যানেল বাধ্যতামূলক (E409): আরপিসি চ্যানেল বাধ্যতামূলক।

বিল্ড কনফিগারেশন

এই অংশে বিল্ড কনফিগারেশন মেসেজের ধরণ ব্যাখ্যা করা হয়েছে।

EBNF ব্যাকরণ

BuildConfiguration = "{" , BuildConfigurationElement, "}" ;

BuildConfigurationElement =
  "target_name" , ":" , String |
  "skip_codegen" , ":" , Boolean
;

প্রোটো সংজ্ঞা

// Defines additional information used to configure build settings
message BuildConfiguration {
  /// Build target name
  optional string target_name = 1;
  // Do not generate code for this service bundle
  optional bool skip_codegen = 2;
}

ব্যবহারের উদাহরণ

build_cfg {
  target_name: "my_custom_target_name"
  skip_codegen: false
}

ব্যাখ্যা

BuildConfiguration কোড জেনারেশনের জন্য ServiceBundle এর ননস্ট্যান্ডার্ড প্যারামিটারগুলো কনফিগার করে। সকল বিল্ড কনফিগারেশন ঐচ্ছিক।

• target_name (ঐচ্ছিক string ): Android.bp ফাইলগুলিতে বিল্ড টার্গেটের নাম নির্দিষ্ট করে। স্বয়ংক্রিয়ভাবে নির্বাচিত নামগুলির চেয়ে ছোট নাম সেট করতে এটি ব্যবহার করুন।
• skip_codegen (ঐচ্ছিক bool ): এই সার্ভিস বান্ডেলের জন্য কোড জেনারেশন এড়িয়ে যাওয়া হবে কিনা তা নির্দেশ করে। যদি এটি ' true সেট করা হয়, তাহলে এই নির্দিষ্ট সার্ভিস বান্ডেলের জন্য কোনো কোড জেনারেট করা হয় না। যেসব সার্ভিস বান্ডেল ম্যানুয়ালি ইমপ্লিমেন্ট করা হয়, তাদের জন্য এটি কার্যকর হতে পারে। ডিফল্টরূপে, এটি ' false সেট করা থাকে।

সীমাবদ্ধতা

• টার্গেট নামের ফরম্যাট (E205, E206, E207, E208): যদি একটি কাস্টম বিল্ড টার্গেট নাম ( build_cfg.target_name ) প্রদান করা হয়, তবে এটিকে অবশ্যই স্নেক কেস ফরম্যাটিং কঠোরভাবে অনুসরণ করতে হবে:
  • এতে শুধুমাত্র ছোট হাতের অক্ষর ( a থেকে z ), সংখ্যা ( 0 থেকে 9 ) এবং আন্ডারস্কোর ( _ ) থাকতে হবে।
  • এতে পরপর দুটি আন্ডারস্কোর ( __ ) থাকতে পারবে না।
  • এটি আন্ডারস্কোর দিয়ে শুরু করা যাবে না।
  • এর শেষে আন্ডারস্কোর থাকা যাবে না।
• টার্গেট নামের অনন্যতা (E301): ব্যবহারকারী-সংজ্ঞায়িত build_cfg.target_name অবশ্যই বিল্ড সিস্টেম জুড়ে অনন্য হতে হবে এবং অন্যান্য সার্ভিস বান্ডেল ডেফিনিশন থেকে প্রাপ্ত স্বয়ংক্রিয়ভাবে তৈরি কোনো টার্গেট নামের সাথে সাংঘর্ষিক হওয়া যাবে না।