Version Sniffing 위에 Feature Detection

날짜로 판을 매긴다 해도, 머릿속 그림은 version 을 눈치보는 게 아니라 기능이 있는지 확인하는 쪽이어야 해. Handshake 의 capabilities object 가 상대편이 뭘 지원하는지에 대한 유일한 진실이야. Revision 번호로 갈라지는 코드는 ('if version >= 2025-11-25 then …') 부실하고, 밝혀둔 capability 로 갈라지는 코드는 ('if 'sampling' in capabilities then …') 어느 revision 에서도 살아남아.

이게 제일 자주 필요한 데가 넘어가는 중인 기능이야. Async task 는 2025-11-25 revision 에 들어왔어. 오래 걸리는 tool 을 부르려는 host 는 async 경로를 고르기 전에, server 가 asyncTasks capability 를 밝히는지부터 봐야 해. Async task 를 알지만 지금 배포 환경에서는 못 돌리는 server 도 있을 수 있거든 — 그럴 땐 그냥 안 밝히면 되고, client 는 그쪽 사정을 몰라도 알아서 맞춰가.

Client capability 쪽도 모양이 같아. Sampling 을 쓰고 싶은 server 는 sampling 요청을 보내기 전에 host 가 sampling 을 밝혔는지 반드시 확인해야 해. 확인 없이 보내면 protocol 위반이고, host 가 연결을 끊어버릴 수도 있어. Capability object 는 기능 스위치판처럼 다루고, version 번호는 기록으로 다뤄.

Code

Feature detection 분기·python

init = await session.initialize()
caps = init.capabilities

# 맞음 — 광고된 capability 로 분기
if caps.get("logging"):
    await session.set_logging_level("info")

# 맞음 — extension 존재로 분기 (async task 는 2025-11-25 추가지만,
# 아무도 날짜 hard-code 안 해도 feature-detection 동작)
if caps.get("experimental", {}).get("asyncTasks"):
    return await call_async(...)
else:
    return await call_sync(...)

잘못 — version sniff·python

# 피해 — server 가 backport 하거나 feature skip 하면 fragile
if init.protocolVersion >= "2025-11-25":
    return await call_async(...)

Code

External links

Exercise

Progress

댓글 0