• Epeg thumbnailing library
  가장 많이 사용되고 있는 이미지 포멧이 JPEG이기 때문에, 이에 대한 thumbnail 기능 지원을 위해 JPEG에 최적화된 Epeg이 제공된다.
  
• Epsilon thumbnailing library
  Epsilon은 PNT, JPEG 및 imlib2, Evas에서 지원하는 이미지 포멧에 대한 thumbnail을 제공한다. 경우에 따라서는 Epeg를 사용하지 않고 Epsilon을 사용해서 JPEG 파일을 지원할 수도 있다.
  
• Esmart utility library
  Esmart는 Edje에 추가적인 능력을 더해주는 helper 라이브러리이다. Esmart를 이용하면 GUI를 위한 컨테이너를 사용할 수도 있고, X root window에 기반한 어플리케이션에서 transparent 효과를 줄 수도 있다. thumbnail 지원을 위한 Epsilon 라이브러리에 대한 인터페이스를 제공하고, 툴킷으로서의 기능(text entries, file dialog box, object drag 등)도 추가해준다.
  
• EWL widget set
  EWL을 이용하면 어플리케이션이 위젯의 형태를 띄도록 할 수 있다.
  
• Imlib2
  Imlib2는 EFL 이전에 등장한 초고속 이미지 처리 라이브러리로 EFL의 라이브러리는 아니다. 많은 시스템에서 이미지 처리를 위해서 사용되고 있으며 EFL에서는 Epsilon 라이브러리가 대표적이다.
  

Figure 3. EFL stack in  programmer's view again

이제 다시 Figure 3을 보고 EFL 라이브러리들의 구조에 대해서 알아보자. 

Figure 3을 보면 각각의 라이브러리들은 상하 의존 관계를 가지고 있지 않으며, 상호 연결 관계에 있어서도 어떠한 방향성도 가지지 않는다. 또한 각 모듈의 크기는 전체 EFL에서의 중요도를 나타낸다.

위의 도식을 설명하면, Evas는 명백하게 EFL에서 가장 중요한 요소이며, Edje는 Evas에 그래픽적 요소를 더해주는 infrastructure 역할을 한다. App1은 도식으로 보아 GUI를 지원하지 않는 콘솔 프로그램일 것이며, App2는 일반적인 형태의 어플리케이션, App3는 위젯 형태의 어플리케이션일 것이다.


아래의 공지를 보면 알 수 있지만, EFL은 아직 완성된 형태의 구조를 갖춘 라이브러리로 보기에는 무리가 있다. 
 

아무도 모르지만, MWC 첫날인 지난 2월 14일에 리모 재단(LiMo Foundation, http://www.limofoundation.org/)이 LiMo4 버전을 공개했다.


지난 기사에 따르면 2010년 5월 LiMo4 표준 선정에서 리모 재단은 삼성전자의 '콜로라도'를 선택했고, 삼성전자가 이를 11월 경 리모 재단에 기증하고, 리모 재단은 이를 LiMo4로 공개한다고 했었다. LiMo4의 발표가 각종 MWC2011 이슈에 묻혀서 완전히 관심 밖으로 벗어나는 바람에 관련 정보는 해당 홈페이지를 제외하고는 전무하다.

우선 알려진 자료를 바탕으로 SLP와 LiMo4 의 구조를 비교해 보자.

다른 모바일 플랫폼이 지원하는 대부분의 기능을 그대로 지원하고 있고, 그나마 특징이 있다면 GUI FW(GTK+, EFL)을 내장하고 있다는 점과 다양한 화면 해상도를 지원한다고 자신있게 내세운다는 점이다.

아직 정확히 판단을 할 수 없지만, LiMo4는 다른 플랫폼이 지원하는 수준까지 이제 레벨을 올려놓은 수준으로 보는 것이 가장 나을 듯 하다. 즉, 특별한 경쟁력을 지녔다고는 볼 수 없기 때문에 앞으로 리모 재단 멤버 회원들의 지원 여부에 따라 성패가 나뉠 것으로 보인다.

게다가 FAQ에 의하면 LiMo4는 Flash, AIR, WAC 런타임을 지원하고, native 개발은 회원사들만 가능하며, 심지어는 자체 eco-system을 구축할 계획도 없다고 한다.

앞날은.........각자의 판단에......

HTML5에는 <h1>~<h6> 요소들을 묶는 <hgroup> 요소가 도입되었다. <hgroup> 요소의 사용 유무는 실질적으로 사용자에게는 드러나지 않는다. 다음 예제를 실행해보면 그 결과를 알 수 있다.



결과 화면은 아래와 같다. (결과링크)

사용자에게 보여주는 화면은 <hgroup> 요소를 사용하나 사용하지 않으나 동일함을 알 수 있다. 하지만 HTML5에는 시멘틱 개념이 도입되었고, 이러한 관점에서는 두 소스 코드는 다른 의미를 가진다.

각각의 컨텐츠를 도식화 해 보면 다음과 같다.

첫번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '하위' 항목이 되고 <p> 요소는 <h2>요소에 대한 설명으로 인식된다.
두번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '부가' 항목이 되고 <p> 요소는 <h1>, <h2>요소에 대한 설명으로 인식된다.

만약 검색 엔진 등 기계적으로 본문에 대한 주제나 요약을 찾을 경우,
첫번째 소스코드에서는 <h2> 요소가 <p> 요소를 대표하게 되고,
두번째 소스코드에서는 <h1>, <h2>요소가 모두 <p> 요소를 대표하게 되는데,
<h1>, <h2> 중 다시 하나를 선별한다면 <h1> 요소가 <p>요소를 대표하게 된다. 

NoSQL(Not only SQL)은 데이터베이스 관리 시스템(Database Management System, DBMS)을 의하는 용어인데, 최근에는 그 동안 사용되어 온 관계형 데이터베이스 관리 시스템(Relational Database Management System, RDBMS)과 대치되는 용어로 자주 사용된다.

덕분에 가장 쉽게 NoSQL에 대한 개념을 정리하려면 RDBMS와 어떻게 다른가를 찾아보면 된다. 대표적으로 정리되는 NoSQL의 특징은 아래와 같다.

• 고정된 테이블 스키마 없음
• 테이블 간의 JOIN 연산을 하지 않음
• 수평적인 확장성이 있음
• 대용량(heavy) 읽기/쓰기 성능이 좋음

개략적은 특징은 위와 같이 정리할 수 있지만, 더 자세한 내용을 알기 위해서는 DB의 기본적인 이론, RDBMS의 특징, NoSQL의 등장 배경 등에 대해서도 알아보아야 한다.


CAP Theorem은 분산형 시스템에서 아래의 세 가지 특성 모두를 제공하는 것이 불가능하다는 것을 언급하고 있는 정리이다.

 

• Consistency : 모든 노드는 동시에 같은 데이터를 가지고 있음
• Availability : 모든 노드는 항상 동작 해야함
• Partition Tolerance : 전체 시스템은 물리적으로 분리된 노드 상에서도 잘 동작해야 함

CAP Theorem에 따르면 위의 세 가지 중에 최대 두가지 특성만을 적용할 수 있고, 때문에 분산형 시스템을 설계할 때는 그 시스템의 특성에 따라 필요한 특성을 골라 시스템을 구성해야 한다.

기존의 RDBMS를 위의 특성에 대입해서 판단한다면, RDBMS가 사용될 당시에는 데이터의 항시성과 무결성이 가장 중요한 요소이었기 때문에 RDBMS는 CA 특성을 가진 시스템에 해당 된다.

하지만 네트워크 발전으로 인해 많은 양의 데이터가 생겨나고 이를 처리하기 위해 클라우드 컴퓨팅 등 분산 처리 시스템이 도입되면서 기존의 RDBMS는 이를 위한 확장성을 지원하는 못하는 한계를 드러내게 된다. 때문에 기존의 RDBMS가 가지는 CA 특성 중 하나를 포기하고 P 특성을 도입하기 위한 다양한 시도들이 나오게 되는데, 그 과정에서 NoSQL이 나타나게 된다.

시스템이 사용되는 환경에 따라서 P를 중심으로 C 또는 A 특성을 추가하게 되는데, 대표적인 실사용예는 다음과 같다.

• Google: BigTable - Consistency + Partition Tolerance
• Amazon: Dynamo - Availability  + Partition Tolerance
• Digg.com: Cassandra - Availability  + Partition Tolerance
• Twitter: Cassandra - Availability  + Partition Tolerance

이처럼 NoSQL이 기존의 RDBMS가 가지던 CA 특성 중 하나를 포기하고 P를 선택함에 따라서 RDBMS가 가지는 일부의 장점을 잃게 되었다. 대표적인 것이 ACID이다.

• Atomic : 데이터 처리의 원자성. 성공 또는 실패만 존재. 처리 중간에 정지할 수 없음
• Consistent : 데이터의 일관성. 서로 다른 세션에서 동시에 참조할 경우 데이터는 항상 동일 해야 함
• Isolated : 데이터 처리 트랜젝션 중에는 다른 세션에서 데이터를 참조할 수 없음
• Durable : 데이터 처리 트랙젝션이 종료되면 완료된 값은 항상 유지되어야 함.

NoSQL의 경우에는 위의 네 가지를 모두 보장하지 않는데, 예를 들면 CAP 중 C를 포기하고 AP를 채용한 Cassandra 같은 경우에는 100%의 Consistency를 포기하고 Eventually consistency를 지원한다. 즉, Cassandra를 이용하는 시스템의 경우 동일한 데이터에 어떤 클라이언트에서는 값을 쓰고, 어떤 클라이언트에서는 값을 읽는 다면 두 클라이언트가 가지는 데이터 값이 다를 수도 있다는 것이다.

NoSQL은 구조화된 스키마를 가지지 않고 STL의 MAP 컨테이너와 유사한 Key-Value 방식으로 데이터를 저장한다.
분류적으로는 Key-Value 방식 이외에도 GraphDB, Documente-Oriented DB, Column-Orinted DB 등이 있지만, 넓은 의미에서 MAP 컨테이너의 Key-Value 방식으로 저장된다고 보면 된다.

NoSQL을 구성하는 아키텍처는 구현하는 시스템에 따라 매우 다양하지만, 큰 공통점은 아래와 같다.

• 각각의 물리적 노드는 내부에 가상의 노드를 가지기도 함
• 가상의 노드는 여러 물리적 노드에 복제본을 가지고 있음 => 물리적 노드 및 그 내부에 가상의 노드를 추가하고 기존의 데이터를 복제함으로써 수평적 확장성 지원
• Key를 기준으로 검색 요청이 올 경우 물리적 노드를 대상으로 Hashing, Tree searching, Key meta server 등을 이용하여 해당 노드에 접근함

특정한 표준에 의해 만들어진 기술이 아닌 필요에 의해서 만들어진 기술이기 때문에 구체적인 내용에서는 많은 차이점을 가진다. 하지만 어떤 NoSQL 제품을 사용하던 개념적인 큰 틀은 이러한 내용에서 벗어나지 않는다고 볼 수 있다.

블로터닷넷에 다음과 같은 제목을 가진 기사가 떴다.

개발자를 위한 Q&A 서비스…”잡담, 저리 가”

바로 프로그래머를 위한 전문 Q&A 사이트인 스택오버플로(stackoverflow, http://stackoverflow.com/)에 대한 안내기사였다.



스택오버플로(stackoverflow)는 특정인에 의해서 운영되는 것이 아니라 WiKi와 같이 사용자에 의해서 운영되고 만들어지는 구조로 되어 있는데, 사용자들은 아무런 비용 부담없이 프로그래밍 관련 질문을 올리고 답변을 하고, 또 기존의 질문과 답변을 검색하고 볼 수 있게 되어 있다. 아주 간단한 기능만을 제공하기 때문에 화면의 구성 또한 아주 단준해서 메인 화면에는 최근에 등록된 질문, 최근에 등록된 게시물의 태그 등이 포시된다.



위의 특징만으로도 충분한 설명이 되지만, 좀 더 알아보기 위해서는 메인화면 우측의 About 링크를 확인하면 된다.
About 페이지에서 확인할 수 있는 스택오버플로(stackoverflow)의 특징을 정리하면 아래와 같다.

- 무료 프로그래밍 Q&A 사이트(a programming Q & A site that's free)
- 프로그래머인 사용자에 의해서 운영됨(collaboratively built and maintained by your fellow programmers)
- Wiki 처럼 수정 가능(Once the system learns to trust you, you’ll be able to edit anything)

그래도 명확하지 않은 사람들이 있을 것 같아서 FAQ 페이지도 준비되어 있다. FAQ 사이트의 내용을 간단하게 정리해보자.

우선 소스코드가 포함된 질문이 제일 좋지만, 특별한 프로그래밍 문제, SW 알고리즘, 개발자들이 많이 쓰는 SW 툴에 대한 질문, 프로그래머란 직업에 대한 것들도 질문해도 된다고 한다.
그리고 당면한 실질적이고 답변 가능한 질문을 해달라는 멘트도 있다. 이말은 다음의 두 예문을 통해 쉽게 이해할 수 있다.

   (1) "I would like to participate in a discussion about ______"
   (2) "I would like others to explain ______ to me"

(1)과 같이 어떤 것에 대한 토론을 원한다면 올리며 안되는 질문이고,
(2)와 같이 어떤 것에 대한 설명을 원한다면 올려도 되는 질문이다.

사이트가 양질의 자료로 가득차고, 완전히 사용자들에 의해서 운영되게 하기 위해서 포인트 및 우수 회원 제도, 뱃지 제도 등을 도입하고 있는데, 질문에 대한 답변에 따라서 포인트나 뱃지를 얻을 수도 있고, 우수 회원으로 선정될 경우 사이트의 운영 및 관리에 대한 권한 또한 생긴다.

전세계적으로 운영되는 사이트이지만 어떠한 기준으로는 분류가 되어 있지 않기 때문에, 원하는 답변을 얻거나 또는 자신의 지식을 공유하기 위해서는 태그를 적극적으로 활용해야 될 필요가 있다.

아래에 보듯이 사람들의 관심이 집중되는 질문은 조회수도 높고, 답변도 빨리 달리는 반면 1분도 안되는 시간 간격으로 등록되었지만 상대적으로 덜 관심을 받는 질문도 있다.


질문을 하나 올림에 있어서도 제목 지정이나 태그 선정 등에 대해서 공을 들어야 될꺼 같다.