Framework/Another Lore2009. 4. 30. 10:48


Wokrspace의 Security의 문제
현재 AL Workspace의 보안 Role 모델은 Window의 탐색기로 시작했다. 
각각의 컴퓨터의 탐색기는 별도의 Root를 가지고 모든 파일을 TreePath로 접근할수 있다.

Storage가 물리적인 의미인 반면에 Workspace는 물리적이 아니라 논리적인 의미이다.

A컴퓨터를 GroupA와 GroupB사용자가 하나의 Storage로 각각 다른 Workspace를 사용할때(하나의 Storage를 2개 이상의 Workspace로 사용할때) GroupA와 GroupB는 별도의 TreePath를 가지며 각각의 Workspace에서 TreePath는 유니크하다. 여기까지는 문제가 없다.

단 Node의 UUID로 접근할때 이를 허용해야 하는가의 문제이다. 이를 허용하면 Workspace가 물리적으로 나뉘어 있을때도 접근을 허용해야 하는 문제가 있다. 허용하지 않으려면 매번 WorkspaceName을 검사해야 한다. 이 문제는 일반적인 규악이 없고 Workspace간의 SharableNode의 문제와 얽히기 때문에 머리에서 쥐가 난다.


프로그램에는 How의 코딩의 문제를 벗어나게 되면 일반적으로 2가지 문제가 있는데 하나는 다른 이해 관계자와 커뮤니케이션의 문제이고 두번째는 무엇(What)을 해야 하는가이다. 이런 종류는 방법이 없는게 문제가 아니라 방법이 너무 많아서 어느게 가장 좋은 방법인가를 지금은 알지 못한다에 문제가 있다.


이 문제를 bleujin식 난제 네이밍관례에 따라 "아들을 아들이라 부르지 못하고.." 문제로 정의하였다.




AL은 국제화
AL은 OR Mapping이 아닌 Repository에 가깝기 때문에 UTF인코딩을 넘어서는 국제화를 지원해야 한다.

이를테면 우리나라는 GMT+9의 Timezone에 있다. 날짜는 절대시간으로서의 인식과 상대시간으로의 인식이 있는데 오스트리아의 오늘 일몰 시간은 오후 07:13분입니다 라고 할때는 절대시간으로서 저장해야 하고 오스트리아의 오후 7시 13분이 우리나라 시간으로 몇시지? 라고 생각하면 상대시간으로 저장해야 한다.

그러나 시간은 말하지 않기 때문에 사용자가 Property에 날짜값을 설정했을때 어느 시간으로 저장해야 하는가에 대한 문제가 있다. 이를테면 호주에서 4월 30일 오후 9시 20분이라고 입력한 것과 우리나라에서 4월 30일 오후 9시 20분이라고 입력한것은 전혀 다르다.

그래서 Calendar Property는 UTC로 저장한다. 그런데 사용자의 접속시간 등 다른 시간들의 표현에 문제가 있다. 난 오전 10시에 로그인했는데 오전 1시에 접속한 걸로 나오면 아마 프로그래밍 버그를 의심할 것이다.

이런 날짜의 문제뿐 아니라 이전 국제화 글에서 지적한 바와 같이 숫자의 표현 등에도 난제는 많다. (통화는 PropertyType에 없다는 것이 좀 위안이 된다. -ㅅ-)  이 것을 "시간의 침묵" 이라고 부르기로 했다. -ㅅ-

'Framework > Another Lore' 카테고리의 다른 글

최근에 책을 읽다가..  (0) 2009.06.11
AL : Permission  (1) 2009.04.30
AL : Workspace  (0) 2009.04.28
AL : Property Type Conversion  (0) 2009.04.26
AL : Reading  (0) 2009.04.25
Posted by bleujin