비슷한 프로젝트들도 있겠지만, BSD 라이선스의 대표적인 프로젝트라 많이들 도입하려고 노력하는 것 같습니다.(자신의 환경과 맞지 않아서 포기도 많이들 하고)
개인적으로 이런 류의 프로젝트에 대해 생각나는 내용은 다음 정도입니다.
- 가능한 최대 데이터의 크기는 얼마정도까지인지?
- 메시지 오브젝트의 toString을 얼마나 보기 좋게 표현가능할지?
- 가변 개수의 반복적인 표현을 할 수 있는지?
- 메시지 중간에 특별한 파라미터 값에 따라 파싱 방법이 달라지는 걸 지원할지?
- 컴포넌트 조합같이, 재귀적으로 다른 메시지의 내용을 포함해서 메시지를 구성할 수 있는지?
- 자바 아닌 다른 언어 지원도 고려할지?
- 비트 지원도 고려할지?
- 파싱 예외를 잘 잡아낼 수 있는지?
- 파라미터 범위등에 대한 validation을 제공하는지? (xml의 Dtd 를 해석해서 ? or xml자체에 개인적)
- 서로 관계가 있는 파라미터끼리도 이런 validation이 가능한지? (x = 1이면 y는 100또는 101이어야 하지만, x = 2라면 y는 200또는 201이어야 하는 제약조건?)
부족하지만 초급 수준(=> 제 수준임)의 프로그램도 만들 수 있는 정도의 소스 빌더 만든 상태입니다.
그래서 그런지 말씀 하시는 내용 대부분 지원하지 않는다는 식의 부정 이네요.
좋은 모습으로 소개를 할 수 있도록 하겠습니다.
(1) 가능한 최대 데이터의 크기는 얼마정도까지인지?
=> 서버와 클라이언트 사이에서 전송될때 설정 파일에서 지정된 크기(= 버퍼갯수 * 버퍼 크기)를 검사합니다.
(2) 메시지 오브젝트의 toString을 얼마나 보기 좋게 표현가능할지?
=> 정보 파일 자체에 모든 정보가 있으므로 toString 만드는거 어렵지 않지만
toString 내용과 실제 내용의 차이점때문에 속도가 느리더라도 자바 리플레션을 이용해야 할지 고민됩니다.
(3) 가변 개수의 반복적인 표현을 할 수 있는지? => 1차원 배열만 지원하며 배열의 반복 횟수는 고정 갯수와 가변 가능합니다. 가변일경우에는 반듯이 위에서 선언한 변수로 지정되어야 합니다.
(4) 메시지 중간에 특별한 파라미터 값에 따라 파싱 방법이 달라지는 걸 지원할지?
=> google protobuf 의 option 을 말씀하시는건가요?
제가 이것의 필요성을 모르기때문에 설계시 고려하지 않았습니다.
이진 데이터의 교환시 가장 어려운것이 1 byte 어긋남으로 상징되는 일 아닙니까?
이 문제 때문에 특별한 파라미터 값에 따른 파싱 방법을 전혀 고려하지 않았습니다.
제가 만든 프로그램에서 파스칼 스트링을 지원하는데요.
파스칼 스트링이 말씀하시는 option 과 유사하게 동작합니다.
파스칼 스트 타입은 문자열 크기를 unsinged byte, unsigned short, signed integer 로 표시한후 문자열 데이터를 전송합니다.
그런데 1byte 어긋남으로 상징되는 일이 발생했을때 도대체 어느 항목에서 어긋났는지 찾기가
파스칼 스트링때문에 더욱 어렵더라구요.
1 byte 어긋남으로 상징되는 것에 대한 해법으로
현재 protobuff 를 비롯한 다른 프로토콜에서 아이디를 얻어서 데이터 타입도 같이 전송해 주는 프로토콜을 준비중입니다.
구현하는데는 별로 어려움은 없지만 우선 순위가 밀려 보류중입니다.
반듯이 넣는다고 장담을 못하지만 이 프로토콜을 구현할때 같이 고려해 보겠습니다.
(5) 컴포넌트 조합같이, 재귀적으로 다른 메시지의 내용을 포함해서 메시지를 구성할 수 있는지?
=> 이것 또한 설계 능력이 되지 않기에 고려하지 않고 있습니다.
하지만 포함해야 하는 메시지가 공통 부분으로 예를 들면 사용자 인증이라고 한다면 보안툴 업그레이드를 해야할때 항목들에 대해서 약간의 조정이 필요 하다면
제가 지금 선택한 방법은 정말로 유지 보수 측면에서 최악이라고 생각하기에 충분히 고민으로 받아 들이고 있습니다.
그렇지만 대상이 되는 메시지 구조를 파악하기 위해서 열어 보았는데 메시지가 포함되어 있어서 포함된 메시지를 열어봐야 하는것은 개인적으로 싫어합니다.
이 부분은 많은 분들께 의견을 구해 봐야겠네요.
(6) 자바 아닌 다른 언어 지원도 고려할지?
=> 예 고려하고 있습니다. 이진데이터인 정수 타입을 지원하는데 바이트 오더 검증을 위해서라도 다른 언어와의 메시지 교환이 필수라고 생각합니다.
다만 현재에는 c 언어 정도 생각하고 있을뿐입니다.
(7) 비트 지원도 고려할지? => 고려하지 않습니다.
(8) 파싱 예외를 잘 잡아낼 수 있는지? => 파싱기가 얼마나 잘 작성되어 있는가 라는 문제로 늘 이런 고민을 하고 만들기는 하지만 저두 사람인지라 2% 이상이 늘 부족합니다.
(9) 파라미터 범위등에 대한 validation을 제공하는지? (xml의 Dtd 를 해석해서 ? or xml자체에 개인적) => 지원하지 않지만 고민 사항입니다. 설계 능력이 없어 못했다 생각하시면 됩니다.
동일 분야는 아니지만, 바이너리 스트림 파싱은 제 업무에서도 많이 사용되고 있고, 여전히 저는 노가다 수정을 하고 있어서,
작성 중이신 것과 비슷한 것을 만들어 볼까 하는 마음은 있었습니다.
그래서, 개인적으로 염두에 두었던 막연한 요구사항들 중 몇 가지를 생각나는 대로 적게 되었습니다. 조언을 드릴만한 입장은 아니었네요~
제가 개인적으로 적은 위 내용들은 크게 신경쓰시지 않으셔도 되지 않을까 합니다.
모든 것을 만족하는 툴이 없듯이, 도메인과 필요성에 따라 제한을 두었다고 해도,
제 역할을 하고 있고, 사용하기 쉽고, 구조가 직관적이라면 이미 귀한 시간을 절약해주는 훌륭한 툴이 되었다고 생각합니다.
해당 도메인에서는 잘 사용되지 않을 구조 등에 불필요한 공을 들이는 것도 의미가 있을 수도 있지만, 시간 낭비일 수도 있으니까요.
protocolBuf를 언급하긴 했지만, 전 자세한 내용은 보질 않았습니다. option이 저런 내용인지 나중에 확인해 보겠습니다. :)
즐. 즐겁게 프로그램 하셔요. :)
즐. 즐겁게 프로그램 하셔요. :)
세벌 https://sebuls.blogspot.kr/
요구분석이 힘들다면 다른 비슷한 프로젝트에서 무엇을
요구분석이 힘들다면 다른 비슷한 프로젝트에서 무엇을 하고 있는지, 참고해 보는게 좋지 않을까 합니다.
그러다가 보면 점차 창조적? 인 요구사항을 만들 수도 있지 않을까 합니다.
바로 직전 게시물을 보니, IO정의 xml -> IO처리 Java 소스 프로젝트인 것으로 보입니다.
이 프로젝트에 대한 고민이 맞다면 아래 내용을 확인해 보세요
비슷한 프로젝트로 구글의 protocolbuf가 있는 줄은 아시죠? 아니라면 아래 url을 참조해 보세요.
https://code.google.com/p/protobuf/
http://skccblog.tistory.com/1011
http://knight76.tistory.com/1366
비슷한 프로젝트들도 있겠지만, BSD 라이선스의 대표적인 프로젝트라 많이들 도입하려고 노력하는 것 같습니다.(자신의 환경과 맞지 않아서 포기도 많이들 하고)
개인적으로 이런 류의 프로젝트에 대해 생각나는 내용은 다음 정도입니다.
- 가능한 최대 데이터의 크기는 얼마정도까지인지?
- 메시지 오브젝트의 toString을 얼마나 보기 좋게 표현가능할지?
- 가변 개수의 반복적인 표현을 할 수 있는지?
- 메시지 중간에 특별한 파라미터 값에 따라 파싱 방법이 달라지는 걸 지원할지?
- 컴포넌트 조합같이, 재귀적으로 다른 메시지의 내용을 포함해서 메시지를 구성할 수 있는지?
- 자바 아닌 다른 언어 지원도 고려할지?
- 비트 지원도 고려할지?
- 파싱 예외를 잘 잡아낼 수 있는지?
- 파라미터 범위등에 대한 validation을 제공하는지? (xml의 Dtd 를 해석해서 ? or xml자체에 개인적)
- 서로 관계가 있는 파라미터끼리도 이런 validation이 가능한지? (x = 1이면 y는 100또는 101이어야 하지만, x = 2라면 y는 200또는 201이어야 하는 제약조건?)
Signature :) - "여유를 갖고 행동하되 게을러지지 말자"
좋은 답변 감사합니다. 대부분 고려사항 모두 NO 라서 절망적이네요.
좋은 답변 감사합니다.
protobuf 는 선망의 대상이지만 구조상 넣기가 어려워서 포기했습니다.
부족하지만 초급 수준(=> 제 수준임)의 프로그램도 만들 수 있는 정도의 소스 빌더 만든 상태입니다.
그래서 그런지 말씀 하시는 내용 대부분 지원하지 않는다는 식의 부정 이네요.
좋은 모습으로 소개를 할 수 있도록 하겠습니다.
(1) 가능한 최대 데이터의 크기는 얼마정도까지인지?
=> 서버와 클라이언트 사이에서 전송될때 설정 파일에서 지정된 크기(= 버퍼갯수 * 버퍼 크기)를 검사합니다.
(2) 메시지 오브젝트의 toString을 얼마나 보기 좋게 표현가능할지?
=> 정보 파일 자체에 모든 정보가 있으므로 toString 만드는거 어렵지 않지만
toString 내용과 실제 내용의 차이점때문에 속도가 느리더라도 자바 리플레션을 이용해야 할지 고민됩니다.
(3) 가변 개수의 반복적인 표현을 할 수 있는지? => 1차원 배열만 지원하며 배열의 반복 횟수는 고정 갯수와 가변 가능합니다. 가변일경우에는 반듯이 위에서 선언한 변수로 지정되어야 합니다.
(4) 메시지 중간에 특별한 파라미터 값에 따라 파싱 방법이 달라지는 걸 지원할지?
=> google protobuf 의 option 을 말씀하시는건가요?
제가 이것의 필요성을 모르기때문에 설계시 고려하지 않았습니다.
이진 데이터의 교환시 가장 어려운것이 1 byte 어긋남으로 상징되는 일 아닙니까?
이 문제 때문에 특별한 파라미터 값에 따른 파싱 방법을 전혀 고려하지 않았습니다.
제가 만든 프로그램에서 파스칼 스트링을 지원하는데요.
파스칼 스트링이 말씀하시는 option 과 유사하게 동작합니다.
파스칼 스트 타입은 문자열 크기를 unsinged byte, unsigned short, signed integer 로 표시한후 문자열 데이터를 전송합니다.
그런데 1byte 어긋남으로 상징되는 일이 발생했을때 도대체 어느 항목에서 어긋났는지 찾기가
파스칼 스트링때문에 더욱 어렵더라구요.
1 byte 어긋남으로 상징되는 것에 대한 해법으로
현재 protobuff 를 비롯한 다른 프로토콜에서 아이디를 얻어서 데이터 타입도 같이 전송해 주는 프로토콜을 준비중입니다.
구현하는데는 별로 어려움은 없지만 우선 순위가 밀려 보류중입니다.
반듯이 넣는다고 장담을 못하지만 이 프로토콜을 구현할때 같이 고려해 보겠습니다.
(5) 컴포넌트 조합같이, 재귀적으로 다른 메시지의 내용을 포함해서 메시지를 구성할 수 있는지?
=> 이것 또한 설계 능력이 되지 않기에 고려하지 않고 있습니다.
하지만 포함해야 하는 메시지가 공통 부분으로 예를 들면 사용자 인증이라고 한다면 보안툴 업그레이드를 해야할때 항목들에 대해서 약간의 조정이 필요 하다면
제가 지금 선택한 방법은 정말로 유지 보수 측면에서 최악이라고 생각하기에 충분히 고민으로 받아 들이고 있습니다.
그렇지만 대상이 되는 메시지 구조를 파악하기 위해서 열어 보았는데 메시지가 포함되어 있어서 포함된 메시지를 열어봐야 하는것은 개인적으로 싫어합니다.
이 부분은 많은 분들께 의견을 구해 봐야겠네요.
(6) 자바 아닌 다른 언어 지원도 고려할지?
=> 예 고려하고 있습니다. 이진데이터인 정수 타입을 지원하는데 바이트 오더 검증을 위해서라도 다른 언어와의 메시지 교환이 필수라고 생각합니다.
다만 현재에는 c 언어 정도 생각하고 있을뿐입니다.
(7) 비트 지원도 고려할지? => 고려하지 않습니다.
(8) 파싱 예외를 잘 잡아낼 수 있는지? => 파싱기가 얼마나 잘 작성되어 있는가 라는 문제로 늘 이런 고민을 하고 만들기는 하지만 저두 사람인지라 2% 이상이 늘 부족합니다.
(9) 파라미터 범위등에 대한 validation을 제공하는지? (xml의 Dtd 를 해석해서 ? or xml자체에 개인적) => 지원하지 않지만 고민 사항입니다. 설계 능력이 없어 못했다 생각하시면 됩니다.
동일 분야는 아니지만, 바이너리 스트림 파싱은 제
동일 분야는 아니지만, 바이너리 스트림 파싱은 제 업무에서도 많이 사용되고 있고, 여전히 저는 노가다 수정을 하고 있어서,
작성 중이신 것과 비슷한 것을 만들어 볼까 하는 마음은 있었습니다.
그래서, 개인적으로 염두에 두었던 막연한 요구사항들 중 몇 가지를 생각나는 대로 적게 되었습니다. 조언을 드릴만한 입장은 아니었네요~
제가 개인적으로 적은 위 내용들은 크게 신경쓰시지 않으셔도 되지 않을까 합니다.
모든 것을 만족하는 툴이 없듯이, 도메인과 필요성에 따라 제한을 두었다고 해도,
제 역할을 하고 있고, 사용하기 쉽고, 구조가 직관적이라면 이미 귀한 시간을 절약해주는 훌륭한 툴이 되었다고 생각합니다.
해당 도메인에서는 잘 사용되지 않을 구조 등에 불필요한 공을 들이는 것도 의미가 있을 수도 있지만, 시간 낭비일 수도 있으니까요.
protocolBuf를 언급하긴 했지만, 전 자세한 내용은 보질 않았습니다. option이 저런 내용인지 나중에 확인해 보겠습니다. :)
Signature :) - "여유를 갖고 행동하되 게을러지지 말자"