IT/Mobile Platforms | Posted by 철규님(최규철) 2011. 3. 2. 00:59

EFL(Enlightenment Foundation Library)이란 무엇인가?



EFL이란 무엇인가?
by GyuCheol Choi(gc8134.choi@gmail.com) on 01 Mar 2011

삼성 SLP 또는 LiMo4 플랫폼의 아키텍처를 보면(2011/02/23 - [Dev/LiMo/SLP/EFL] - LiMo4? SLP?), UI 프레임워크로 GTK+와 EFL을 지원한다고 나와있다. GTK+는 Gimp ToolKit의 약자로 이미 오래전부터 사용되어 온 프레임워크로 관련 정보를 많이 찾을 수 있지만, EFL에 대한 정보는 아직 많이 제공되고 있지 않다. 간단하게 EFL이 무엇인지 정리를 해보려고 한다.

Enlightenment? EFL?
Enlightenment는 Linux/X11 등을 위한 Windows manager를 의미하기도 하고, 기존의 toolkit 보다 더 적은 작업으로 더 보기 좋은 UI 제작을 가능하게 하는 것을 목표로 하는 프로젝트의 이름을 의미하기도 한다. 이 개발 환경은 휴대폰과 같은 소형기기부터 노트북, 데스크탑과 같은 기기까지 지원한다.

EFL은 Enlightenment Foundation Library의 약자로 Enlightenment windows manager의 GUI 구현을 위한 라이브러리인데, 정확하게는 각각의 목적과 기능을 가진 라이브러리의 셋으로 볼 수 있다.

Enlightenment 홈페이지(http://www.enlightenment.org)에서 EFL의 구조를 찾으면 세 가지의 그림을 찾을 수 있다.

Figure 1. EFL stack with essentials

 
Figure 2. EFL stack by Marketing department


Figure 3. EFL stack in  programmer's view


전체적인 구조를 간단하게 나타내기 위한 것이 Figure 1이며, 상세한 정보를 나타내는 것이 Figure 2와 Figure 3인데 동일한 contents로 이렇게 다른 view가 나온 것에 대해서는 관련된 설명을 보자.

다양한 라이브러리의 구조 설명을 위해서 도입된 박스 형태의 도식(Figure 2)은 상위 레벨은 하위 레벨에 의존성을 가지고, 프로그래머는 상위 레벨의 요소들만 이용해야 하며 하위 레벨의 요소들을 직접 컨트롤해서는 안된다는 의미를 가진다. 하지만 EFL 라이브러리들은 이러한 상하 의존적 관계를 구성하고 있는 것이 아니기 때문에 Figure 2와 같이 상화 관계를 강조한 도식보다는 FIgure 3과 같이 상호 작용을 강조한 도식이 실제적인 EFL의 구조를 설명하는데 더 적합하다.

Figure 3을 정확히 이해하기 위해서는 각각의 요소들이 무엇인지에 대한 이해가 필요하므로, 간단하게 이것에 대해서 알아보고 다시 FIgure 3에 대해서 이야기해 보자.

  • Ecore glue library
    Ecore는 GTK+의 Glib와 비교할 수 있는데, EFL의 주요 요소들을 하나로 모아서 사용자 어플리케이션이 사용할 수 있도록 해주는 역할을 한다. data structure, IPC mechanism, easy networking, helper function 등을 제공하고 UNIX/X 시스템의 일부 common 기능에 대한 abstraction도 제공한다. Graphic적인 요소가 없는 어플리케이션에서도 Ecore를 사용할 수 있다.
  • Evas canvas
    Evas는 강력한 canvas로, X11 toolkit의 canvas widget보다 훨씬 더 진일보한 환경을 제공한다. Evas는 스크린에 어떤 것이 렌더링되었는지에 대한 정보를 모두 보유하고 있으며, 각각의 Evas object들은 "draw and forget" object의 성격을 띈다 . 즉, 사용자가 rectangle을 그리면 이것을 인지하고, 외부 data structure의 도움 없이도 move나 resize 등을 가능하게 하며, 프로그래머는 각 object의 state를 저장하고 있을 필요도 없고, redrawing이나 repainting에 대해서도 신경 쓸 필요가 없다. Evas는 매우 최적화되어 있어서 제한된 memory나 저수준의 processor를 가진 임베디드 시스템에서도 사용이 가능하다. X11의 back-end로 OpenGL이나 Xrender, frame-buffer device에서도 동작한다.
  • Edje layout engine
    Edje를 이용하면 C 코드를 단 한 줄도 코딩하지 않고 GUI를 구현할 수 있다. 인터페이스가 어떻게 구성되고 스크린에 어떻게 나타나며 어떻게 동작하는지만 작성하면, Edje가 low level code와 하나의 테마 파일에 모든 것이 포함된 번들을 만들어준다. 이를 이용하면 어플리케이션을 C 코드에 대해서는 전혀 모르는 graphical part와 GUI에 대해서는 전혀 모르는 functionality part로 나누어서 작성할 수 있다. 덕분에 GUI를 건드리지 않고 기능을 변경하거나, 기능을 변경하지 않고 GUI를 수정하는 등의 작업을 매우 쉽게 할 수 있다. 어플리케이션의 사용자 또한 자신의 테마를 만들어서 곧바로 적용할 수 있다.
  • Eet storage library
    대부분의 테마들은 하나의 파일로 전달되지만 설치 과정에서 압축이 풀리고 어플리케이션은 이 압축이 풀린 테마 파일'들'을 사용한다. Eet는 전혀 다른 방법을 사용하는데, 테마 파일은 압축이 풀리지 않은 상태에 있다가 어플리케이션의 UI를 구성하기 위해 필요한 때 Eet에 의해서 읽혀진다. 또한 Eet는 일반적인 storage의 역할도 한다.
  • Embryo scripting language
    Embryo는 마치 HTML에 Javascript, Flash, AJAX 등이 더해져서 동적인 UI가 가능해진 것 처럼, 테마 구성에 있어서 더 동적인 UI 구조를 만들 수 있게 한다.
  • 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은 아직 완성된 형태의 구조를 갖춘 라이브러리로 보기에는 무리가 있다. 
 

Enlightenment News

1.0 Release of core EFL

Carsten Haitzler - Jan 29, 2011 at 03:40 AM

Finally after a long time coming, we are pleased to announce the 1.0 release of the core EFL libraries (With the exception of Eet at 1.4). The following libraries have been released:

You can download the respective libraries from our Download Page.




아직 1.0까지 밖에 릴리즈가 안된 상태이어서 앞으로도 많은 변화가 있을 것으로 예상된다.

홈페이지의 자료를 찾다보면 Doc의 문서와 Release 관련 문서에서 많은 차이점들을 찾을 수 있는데, 정확한(사실은 더 최신의) 정보를 얻기 위해서는 News의 공지를 바탕으로 Release 관련 정보를 확인하는 것이 좋은 방법일 듯 하다.

댓글을 달아 주세요

IT/Mobile Platforms | Posted by 철규님(최규철) 2011. 2. 23. 23:50

LiMo4? SLP?



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


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

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

SLP와 LiMo4의 아키텍쳐를 비교해보면 프레임워크 구분이나 네이밍에 있어서 약간의 차이가 있지만 거의 동일한 구조를 가지고 있음을 알 수 있다.

코어로는 Linux를 사용하고, X-Window 기반으로 GTK+, EFL 등이 UI FW로 사용되고 있다. WebKit-gtk, WebKit-efl 까지 포함하면 LiMo는 GTK+ 어플리케이션, EFL 어플리케이션, 웹 어플리케이션을 구동할 수 있다.

LiMo4의 주요 특징은 아래와 같다.(http://www.limofoundation.org/en/what-is-the-platform.html)

  • flexible and powerful user interface
  • extended widget libraries
  • 3D window effects
  • advanced multimedia
  • social networking
  • location based service framework
  • sensor framework
  • multi-tasking
  • multi-touch
  • scalable screen resolution

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

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

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

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

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 소혼 2011.02.24 00:02 신고

    정보를 잘 찾네. 다양한 화면 해상도를 지원하는것은 EFL의 큰 장점중 하나지.

  2.  댓글주소  수정/삭제  댓글쓰기 zelon 2011.03.13 15:49 신고

    native 개발은 회원사들만 가능하며...... 오픈인 리눅스를 기반으로 만들면서 좀 의아하네 -_-; 후발주자이면서 무슨 배짱인지 -0-

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 23. 21:28

HTML5에서 <hgroup> 요소의 의미

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


<!DOCTYPE html>
<html>
<head>
  <title>HTML5 - <hgroup> element 테스트</title>
</head>
<body>

<h1>장원준 "개막전 선발 욕심 있다"</h1>
<h2>日롯데 2군에 5이닝 무실점</h2>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다.</p>

<hgroup>
  <h1>장원준 "개막전 선발 욕심 있다"</h1>
  <h2>日롯데 2군에 5이닝 무실점</h2>
</hgroup>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다. </p>

</body>
</html>

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



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

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



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

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

댓글을 달아 주세요

IT/Tech Notes | Posted by 철규님(최규철) 2011. 2. 23. 01:22

NoSQL - 클라우딩 컴퓨팅 환경에서의 데이터 관리



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 제품을 사용하던 개념적인 큰 틀은 이러한 내용에서 벗어나지 않는다고 볼 수 있다.

댓글을 달아 주세요

IT/Computing | Posted by 철규님(최규철) 2011. 2. 22. 23:10

stackoverflow- 프로그래머를 위한 전문 Q&A 사이트


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

개발자를 위한 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분도 안되는 시간 간격으로 등록되었지만 상대적으로 덜 관심을 받는 질문도 있다.


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

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 Codeflow 2013.07.02 22:48

    stackoverflow 한글판이 있으면 좋겠다고 생각하여 codeflow.co.kr 을 만들었습니다. 구경오시고, 질문도 올려주시면 성실히 답변드려요~