저는 최근에 스칼라를 배웠고 리프트 프레임 워크를 배우기 시작했습니다. 기능을 살펴보고 프레임 워크를 시작하면서 역 아약스와 혜성을 포함한 프레임 워크의 놀라운 기능을 보았습니다. 이전에 저의 경험에 비추어 본 적이없는 역방향 아약스에 대한 경험은 정말 좋지 않았습니다. 개발을위한 리프트 프레임 워크를 선택하면 이것이 원인 일 것입니다. 여기 내 질문은 기술과 제품이 얼마나 성숙한 지, 그리고 바람둥이에서 리프트를 사용하면 얼마나 확장 성이 좋습니까? 서블릿 스펙 3.0과 비교하면 서블릿 스펙 3.0을 기다리거나 리프트를 사용하기 시작 했습니까?리프트 프레임 워크의 혜성/역방향 아약스는 얼마나 확장 성이 있습니까?
역방향 AJAX 은 혜성입니다. 그들은 똑같은 두 가지 이름입니다. 질문의 근원은 ...
리프트의 혜성 지원의 확장 성은 서블릿 컨테이너에 크게 달려 있습니다. 정말로에는 기본적으로 연속성을 지원하는 컨테이너가 필요합니다. 부두는 내가 잘 알고있는 사람이지만, 나는 다른 사람들이 있다는 것을 확신한다. 컨테이너 수준에서 계속 지원을 받으면 Comet의 확장 성 문제가 대부분 발생하는 클라이언트 당 스레드를 잠그지 않아도됩니다.
확장 성의 다른 영역에서 Lift의 CometActor은 활성 긴 폴링을 사용하는 단일 클라이언트에 대한 일반적인 추상화입니다. 이 추상화는 액터이기 때문에 기존 액터 프레임 워크 (Scala stdlib for Lift 1.0.x 또는 Lift Actor on 2.0)에서 처리 할 수 있습니다. 이것 역시 스레드 확장의 문제를 피하고 보류중인 업데이트가 순서대로 대기열에 넣어 지도록합니다.
즉, Lift 's Comet 지원은 Comet만큼 확장이 가능합니다. 물론 기술과 관련된 고유의 간접비가 있습니다. 클라이언트 당 적어도 하나의 소켓을 커밋하는 것을 피할 수 없을 것입니다. 그러나 Lift (연속 사용 가능 컨테이너와 함께)는 즉시 필수가 아닌 모든 오버 헤드를 완화 할 수 있습니다.