ما مدى قابلية التوسع في المذنب/عكس إطار المصعد؟

Question

لقد تعلمت مؤخرًا Scala وعلى وشك البدء في إطار العمل/التعلم. مع مرور الميزات والبدء في الإطار ، رأيت بعض القدرات المذهلة للإطار بما في ذلك Ajax و Comet العكسي. في وقت سابق من تجربتي ، كانت لدي تجربة سيئة حقًا مع Ajax العكسي التي لم يتم تحجيمها أبدًا. إذا اخترت Lift Framework لأي تطور ، فسيكون هذا هو السبب. سؤالي هنا هو ما مدى نضوج التكنولوجيا والمنتج وكم هو قابلية للتطوير باستخدام المصعد على Tomcat؟ مقارنة بـ Servlet Spec 3.0 أيهما أفضل لهذا الغرض ، انتظر Servlet Spec 3.0 أو البدء في استخدام المصعد؟

Answer 1

عكس أياكس هو مذنب. إنهما مجرد اسمين مختلفين لنفس الشيء. أما لجذر سؤالك ...

تعتمد قابلية دعم المذنب في LIFT كثيرًا على حاوية Servlet. أنت حقًا تحتاج إلى حاوية تدعم الاستمرارية أصلاً. Jetty هو الشخص الذي أعرفه ، لكنني متأكد تمامًا من وجود آخرين. من خلال الحصول على دعم استمرار على مستوى الحاويات ، يمكنك تجنب قفل خيط كل عميل ، وهو المكان الذي تنبع منه معظم مشكلات قابلية التوسع في المذنب.

في مجالات أخرى من قابلية التوسع ، رفع CometActor هو التجريد العام حول عميل واحد مع دورة طويلة نشطة. نظرًا لأن هذا التجريد هو ممثل ، يمكن معالجته ضمن إطار الممثل الحالي (Scala stdlib for Lift 1.0.x ، أو الجهات الفاعلة في 2.0). هذا يتجنب أيضًا مشكلة تحجيم الخيط ويضمن أن تحديثات معلقة سيتم تصويرها بطريقة منظمة.

باختصار ، يكون دعم المذنب في Lift قابلاً للتطوير كما يمكن أن يكون المذنب. هناك بالطبع النفقات العامة الجوهرية المرتبطة بهذه التقنية. لن تكون قادرًا أبدًا على تجنب ارتكاب مقبس واحد على الأقل لكل عميل. ومع ذلك ، فإن المصعد (جنبًا إلى جنب مع حاوية تدعم الاستمرارات) قادر على التخفيف من أي عام غير ضروري مباشرة خارج الصندوق.