exip-develop — Development

Re: [Exip-develop] Incremental/push parsing?

[Rumen K. <kju...@gm...>]

Hi Robert,

Very good question! I have received similar requests already.
As you wrote, EXIP assumes blocking IOStream interface which is not an
option is many cases.

The simplest and probably the best solution is to reuse the
EXIP_BUFFER_END_REACHED error code.
Then you do the usual iterative parsing of events but when you get
EXIP_BUFFER_END_REACHED you stop the processing and resume when more data
is available and it is added to BinaryBuffer:

while(tmp_err_code == EXIP_OK)
{
tmp_err_code = parseNext(&testParser);
}

        if(tmp_err_code == EXIP_BUFFER_END_REACHED)
        {
                /* Stop processing here, when data is available add it to
BinaryBuffer and resume the while loop over parseNext() */
        }

If you think this API is good I suggest we add this discussion as a feature
request (http://sourceforge.net/p/exip/feature-requests/)
It is fairly simple to implement but there are quite a lot of caveats:
-> the new data needs to be properly added to the BinaryBuffer (taking care
of already full buffer etc.)
-> the parseNext(); call that cause EXIP_BUFFER_END_REACHED might have
updated the EXIP context (such as bufferIndx, bitPointer, currAttr,
currNonTermID, currQNameID etc.) before reaching the end of the buffer so
the context before each parseNext() should be stored and restored in case
of EXIP_BUFFER_END_REACHED error.

Regards,
Rumen





On Fri, May 9, 2014 at 11:39 PM, Robert Varga <ni...@hq...> wrote:

> Hello,
>
> I have been looking at ways on how to enable seamless integration of EXI
> with current projects.
>
> Best approach I found so far is to bridge the EXIP and libxml2 APIs,
> with an introduction of methods which would emit libxml2 SAX callbacks
> from parsing an EXI stream using EXIP.
>
> In order to do this, though, I would need an ability to parse the EXI
> stream as the data comes in, e.g. not have a complete stream
> pre-buffered -- this ability would be a gateway to implementing the
> equivalent of xmlCreatePushParserCtxt() and xmlParseChunk(), which could
> then be fed into the rest of libxml2 interfaces -- adding application
> support for free with minimum system resources.
>
> Unfortunately I have not found an EXIP parsing mode which would be able
> to support this interface. All I found was the IOStream interface, which
> hints at the need to be able to immediately supply more bytes as the
> parser needs them. This is pretty much impossible if the stream is
> coming from network -- without having a thread-per-connection type of
> setup.
>
> Are there any plans to support a push-parser type interface?
>
> Thanks,
> Robert
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Exip-develop mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exip-develop
>

[Exip-develop] Incremental/push parsing?

[Robert V. <ni...@hq...>]

Hello,

I have been looking at ways on how to enable seamless integration of EXI 
with current projects.

Best approach I found so far is to bridge the EXIP and libxml2 APIs, 
with an introduction of methods which would emit libxml2 SAX callbacks 
from parsing an EXI stream using EXIP.

In order to do this, though, I would need an ability to parse the EXI 
stream as the data comes in, e.g. not have a complete stream 
pre-buffered -- this ability would be a gateway to implementing the 
equivalent of xmlCreatePushParserCtxt() and xmlParseChunk(), which could 
then be fed into the rest of libxml2 interfaces -- adding application 
support for free with minimum system resources.

Unfortunately I have not found an EXIP parsing mode which would be able 
to support this interface. All I found was the IOStream interface, which 
hints at the need to be able to immediately supply more bytes as the 
parser needs them. This is pretty much impossible if the stream is 
coming from network -- without having a thread-per-connection type of setup.

Are there any plans to support a push-parser type interface?

Thanks,
Robert

Re: [Exip-develop] Linking Errors

[Rumen K. <kju...@gm...>]

It seems you haven't linked encodeTestEXI.obj
with ASCII_stringManipulate.obj, EXISerializer.obj and others.
Use the provided make script for building the examples and the library-
build/gcc/Makefile

I hope that helps!
Rumen


On Mon, Mar 31, 2014 at 9:51 AM, 张浩（Hao Zhang） <hao...@12...> wrote:

> Dear Members:
> I runned the file "encodeTestEXI.c". After compiling, I linked them. There
> are four errors as follow.
>
> Linking...
> >>> encodeTestEXI.obj : error LNK2001: unresolved external symbol _asciiToString
> >>> encodeTestEXI.obj : error LNK2001: unresolved external symbol _serialize
> >>> exipe.obj : error LNK2001: unresolved external symbol _destroySchema
> >>> exipe.obj : error LNK2001: unresolved external symbol
> >>> _generateSchemaInformedGrammars
> >>> Debug/test.exe : fatal error LNK1120: 4 unresolved externals
> >>> Excute link.exe Error.
> >>>
> >>> test.exe - 1 error(s), 0 warning(s)
>
> How can I do to finishing linking?
>
> Best regards
>
>                                   Jerry
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Exip-develop mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exip-develop
>
>

[Exip-develop] Linking Errors

[张浩（Hao Z. <hao...@12...>]

Dear Members:
I runned the file "encodeTestEXI.c". After compiling, I linked them. There are four errors as follow.
Linking...
>>> encodeTestEXI.obj : error LNK2001: unresolved external symbol _asciiToString
>>> encodeTestEXI.obj : error LNK2001: unresolved external symbol _serialize
>>> exipe.obj : error LNK2001: unresolved external symbol _destroySchema
>>> exipe.obj : error LNK2001: unresolved external symbol
>>> _generateSchemaInformedGrammars
>>> Debug/test.exe : fatal error LNK1120: 4 unresolved externals
>>> Excute link.exe Error.
>>>
>>> test.exe - 1 error(s), 0 warning(s)
How can I do to finishing linking?
Best regards
                                  Jerry

Re: [Exip-develop] Regarding 'Decimal' data type

[Rumen K. <kju...@gm...>]

Hi Durgaprasad,

This is a known issue. The _Decimal64 type is a fixed point decimal number
defined as a GNU extention so I would guess you are not using gcc for
compilation. This will be fixed in the next release. A temporary fix that
you can do is to put the following line:
#define EXIP_DECIMAL float

in build/gcc/pc/exipConfig.h

It does not fix the problem with the decimals but at least compiles.

Regards,
Rumen

On Tue, Feb 14, 2012 at 6:45 AM, Durgaprasad Pawar <
dur...@gm...> wrote:

> Hi,
>     I am having a problem while compiling the source code for exip-0.3.
> Can you please help me with this? I have described the problem in the
> e-mail below.
>
> Regards,
> DP
>
>
> ---------- Forwarded message ----------
> From: Durgaprasad Pawar <dur...@gm...>
> Date: Tue, Feb 14, 2012 at 11:12 AM
> Subject: Regarding 'Decimal' data type
> To: exi...@li...
>
>
> Hi,
>     I am trying to compile the source code of 'exip-0.3'. However, it is
> failing to find the definition of 'Decimal'.
>
> Following is the error message that I get after doing 'make all'
>
>
> ################################################################################
>
> mkdir -p ../../bin
> make: Warning: File `../../include/procTypes.h' has modification time
> 6.7e+03 s in the future
> gcc -c -Wpacked -Wall -O0 -g  -I../../src/common/include
> -I../../src/grammar/include -I../../src/stringTables/include
> -I../../src/contentIO/include -I../../src/streamIO/include
> -I../../src/grammarGen/include -I../../include -Ipc
> ../../src/common/src/ASCII_stringManipulate.c -o
> ../../bin/ASCII_stringManipulate.o
> In file included from ../../include/stringManipulate.h:47,
>                  from ../../src/common/src/ASCII_stringManipulate.c:45:
> ../../include/procTypes.h:199: error: parse error before "Decimal"
> ../../include/procTypes.h:199: warning: type defaults to `int' in
> declaration of `Decimal'
> ../../include/procTypes.h:199: warning: data definition has no type or
> storage class
> make: *** [../../bin/ASCII_stringManipulate.o] Error 1
>
>
> ################################################################################
>
> The procTypes.h file has following for 'Decimal'
>
> #ifndef EXIP_DECIMAL
> # define EXIP_DECIMAL _Decimal64
> #endif
>
> EXIP_DECIMAL Decimal;
>
>
> Do I need to declare my own definition of Decimal here? Or am I missing to
> include some files that contain this definition?
>
>
> Regards,
> DP
>
>

[Exip-develop] Regarding 'Decimal' data type

[Durgaprasad P. <dur...@gm...>]

Hi,
    I am trying to compile the source code of 'exip-0.3'. However, it is
failing to find the definition of 'Decimal'.

Following is the error message that I get after doing 'make all'

################################################################################

mkdir -p ../../bin
make: Warning: File `../../include/procTypes.h' has modification time
6.7e+03 s in the future
gcc -c -Wpacked -Wall -O0 -g  -I../../src/common/include
-I../../src/grammar/include -I../../src/stringTables/include
-I../../src/contentIO/include -I../../src/streamIO/include
-I../../src/grammarGen/include -I../../include -Ipc
../../src/common/src/ASCII_stringManipulate.c -o
../../bin/ASCII_stringManipulate.o
In file included from ../../include/stringManipulate.h:47,
                 from ../../src/common/src/ASCII_stringManipulate.c:45:
../../include/procTypes.h:199: error: parse error before "Decimal"
../../include/procTypes.h:199: warning: type defaults to `int' in
declaration of `Decimal'
../../include/procTypes.h:199: warning: data definition has no type or
storage class
make: *** [../../bin/ASCII_stringManipulate.o] Error 1

################################################################################

The procTypes.h file has following for 'Decimal'

#ifndef EXIP_DECIMAL
# define EXIP_DECIMAL _Decimal64
#endif

EXIP_DECIMAL Decimal;


Do I need to declare my own definition of Decimal here? Or am I missing to
include some files that contain this definition?


Regards,
DP

[Exip-develop] doxygen.patch

[<kbe...@ea...>]

Rumen,

Thanks for your effort on the project. My company is considering use of exip in a project. I'll probably have more questions, but wanted to submit a quick patch for doxygen generation. The following command line:

./build/gcc$ make doc

generates html docs below the 'doc' directory. Happy to revise as needed.

Ken Bannister

Re: [Exip-develop] Reply

[Rumen K. <kju...@gm...>]

Hi Adam,

Please find my comments below:


On Fri, Jul 30, 2010 at 7:38 PM, <org...@us...> wrote:

>
> Message body follows:
>
> Sorry I haven't gotten back to you sooner, I have taken a
> look at some of the materials you have provided links for
> and the code framework you have provided.
>

I also haven't been very active on the project recently - I've been on
vacation. I'll start work in 2-3 weeks and then I expect the real work on
the project to start.

It is my understanding that you want to develop a EXI
> 'decoder' for use in embedded devices (which is why you have
> stated a preference for C).
> This decoder would take a EXI stream and separate out the
> the shortened tags , including taking those elements which
> have been coding into something similar to a Huffman coding.
>

Yes, the goal is to implement efficient 'decoder', but also 'encoder' which
takes XML infoset (http://www.w3.org/TR/xml-infoset/) elements like
attributes, namespaces etc. and encode them in an EXI stream. This works the
opposite compared to the decoder.
I have not include 'encoder' headers because they are analogous to the
decoder so we can start with only decoding EXI and then extend it with the
opposite functionality. Of course, it is also possible to work on
the  'decoder' and 'encoder' at the same time.


> At the end of this process there would only an XML stream
> that could be read by embedded devices.
>

Not only read but also write EXI streams.


> Just a quick thought, would you prefer a dynamically sizing
> array for the "Huffman" parts (slower but more capable), or
> start would you rather start out with a static array that
> could later be re-sized?
>

Hmm, that goes quite deep into implementation details that I haven't thought
about yet but I am not sure we need to represent the
"Huffman" parts or "event codes" as they are referred to in the
specification using arrays. Although they are depicted as a 1 to 3 integers
separated by dots, in the EXI stream they are encoded as a sequence of
bits.
It might be more convenient to store them that way, but of course this must
be considered further. We also can use linked list, stack or something
similar. Before deciding what to use we need to look at the ways we are
going to use the  "event codes". For example: write them as bits when
encoding a EXI stream, read them from a stream - these operations include
reading and writing a  various bits sequences the length of which is
determined by the grammar. Also, when distinguishing between a set of
possible codes a fast comparison between the code from the stream and the
set of possible ones provided by the grammar is needed.

I also remember from class that C array are different in the
> fact that you can access elements outside of the array from
> the array (this is some type of memory leak if I remember
> correctly).
>
> I have been kinda quiet so far because I feel I haven't had
> anything to submit as of yet.
> Thanks.



Also, I would like to ask you to subscribe to exip-develop mailing list (
https://lists.sourceforge.net/lists/listinfo/exip-develop), if you
haven't done so, and post your questions there so that all of us receive the
information.

Regards,
Rumen

Re: [Exip-develop] Getting in track

[Rumen K. <kju...@gm...>]

Hi Ashok,

Thank you for your feedback from what you have read about EXI. I think this
is helpful for all of us.
Also in my opinion you are on the right track.

To follow your example, here I am sharing some thoughts and links that were
useful for me to grasp the EXI grammars:

 - As it is stated a number of times in the EXI specification, the EXI
format uses the formal language theory to encode the information
efficiently. I found it really useful to recall some of the theory
from discrete mathematics related to formal languages and grammars. In
particular the "production rules" which weren't explained in the
specifications became clear. For example:

tartTagContent :
                             EE                                  0.0
                             AT (*) StartTagContent      0.1
                             NS StartTagContent          0.2
                             SC Fragment                    0.3

tartTagContent - LeftHandSide;  Non-terminal symbol as defined by  "regular
grammars"
EE, AT, NS, SC - terminal symbols

StartTagContent, StartTagContent, Fragment
- RightHandSide Non-terminal symbols

The theory explained in http://en.wikipedia.org/wiki/Formal_grammar especially
the paragraph for Regular grammars turned out to be extremely useful for
me.

Regards,
Rumen

On Thu, Jul 22, 2010 at 7:30 PM, Ashok Gowtham <ash...@gm...>wrote:

>  Hello Everyone,
>    I read a part of the EXI format and I felt that I could share what I
> learnt. So that, it will help the other team-mates in getting started with
> the project's flow. (and also get me in the right track)
>
> It's just my opinion, so correct me if I am wrong.
>
> First let me just brush up what the project is about:
>
>    - We have an XML file (or more technically an XML stream)
>    - We need to compress it efficiently (conforming to W3C format)
>    - We use c-language so that we can port to embedded systems
>
>  Here is an overview about XML
>
>    - An easy to use general Data structure
>    - A Data structure that is a super set of HTML's structure ( That is,
>    the structure looks more like HTML)
>    - "Highly Flexible"or in other words, "generic" method to store any
>    data
>    - Wide spreading common file format
>
> A Sample XML data:
>
>> <classroom level="5" section="B">
>>          <student name="Abc1" age="10" />
>>          <student name="Abc2" age="10" />
>>          <student name="Abc3" age="11" />
>>          <student name="Abc4" age="11" />
>> </classroom>
>
>
> Although XML has so many benefits, the main "drawback"(in a particular
> sense)  is that it is *not a binary format*,  and also *it is not
> compressed*
> So the EXIF(Efficient XML Interchange Format) is used to *compress/convert
> it to binary data*. (Which is small enough for network transfer)
>
>  Here is an overview about the EXIF
>
>    - It separates the structure of the file from the contents of the file
>      that is,
>    1. the "tree structure" alone without the values/details   (called as
>       events in relation with streams)
>       2. the details/values alone without the structure  (called as
>       content or simply values)
>       (Remember, the separation is just in terms of the naming not actual
>    separation of data!)
>    - (The EASIEST part)  The tags are simply converted into binary data in
>    the same order as they appear in the file/stream.
>    - It uses state based encoding (more later)
>    - The First work is: Encoding the tags,attributes,content,(everything)
>    using the notations (notations :
>    http://www.w3.org/TR/exi-primer/#exiBody )
>        These notations are the things that are defined by "Grammar"
>    - Next the notations in the grammar are given their binary equivalents
>    - Finally the whole binary document is merged.  :-)
>
>
> Note: There are also specific details as to how each data( values or
> content )  has to be encoded in binary format
>                 (that is, how an integer is to be encoded, and so on...)
>
>
> By the way, What are these "state" things?
>
>    - As we start converting the XML file/stream, we traverse through the
>    XML content sequentially.
>    - At any given point of time we are at a particular( so called) "state"
>    - The notations used in the grammar(
>    http://www.w3.org/TR/exi-primer/#exiBody ) best shows what states might
>    look like
>
> For a simple example, consider,
>
>> <classroom level="5"></classroom>
>>
> Here, as we start converting,
>
>    1. first we encounter a start of a tag.  ( now we are at the state :
>    "start of tag" )
>         then we could expect to see its attributes
>    2. we have an attribute "level" ( now we change state to "attribute" )
>    3. then we have the attribute's value ("*Attribute*'s value" because we
>    came to this state from the state of "attribute")
>
> This can very well mapped to "Events" also.
> That is,
>
>    1. Event of "Occurrence of starting of a tag"
>    2. Event of "Occurrence of an attribute"
>    3. Event of "Occurence of an attribute's value"
>
> I hope this is helpful as a good starter (although it lacks necessary
> details)
>
> I'll try to give more details as and when read through them ( and probably
> understand them :-)
>
> Regards,
> Ashok Gowtham
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Exip-develop mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exip-develop
>
>

[Exip-develop] Getting in track

[Ashok G. <ash...@gm...>]

 Hello Everyone,
   I read a part of the EXI format and I felt that I could share what I
learnt. So that, it will help the other team-mates in getting started with
the project's flow. (and also get me in the right track)

It's just my opinion, so correct me if I am wrong.

First let me just brush up what the project is about:

   - We have an XML file (or more technically an XML stream)
   - We need to compress it efficiently (conforming to W3C format)
   - We use c-language so that we can port to embedded systems

 Here is an overview about XML

   - An easy to use general Data structure
   - A Data structure that is a super set of HTML's structure ( That is, the
   structure looks more like HTML)
   - "Highly Flexible"or in other words, "generic" method to store any data
   - Wide spreading common file format

A Sample XML data:

> <classroom level="5" section="B">
>          <student name="Abc1" age="10" />
>          <student name="Abc2" age="10" />
>          <student name="Abc3" age="11" />
>          <student name="Abc4" age="11" />
> </classroom>


Although XML has so many benefits, the main "drawback"(in a particular
sense)  is that it is *not a binary format*,  and also *it is not compressed
*
So the EXIF(Efficient XML Interchange Format) is used to *compress/convert
it to binary data*. (Which is small enough for network transfer)

 Here is an overview about the EXIF

   - It separates the structure of the file from the contents of the file
     that is,
   1. the "tree structure" alone without the values/details   (called as
      events in relation with streams)
      2. the details/values alone without the structure  (called as content
      or simply values)
      (Remember, the separation is just in terms of the naming not actual
   separation of data!)
   - (The EASIEST part)  The tags are simply converted into binary data in
   the same order as they appear in the file/stream.
   - It uses state based encoding (more later)
   - The First work is: Encoding the tags,attributes,content,(everything)
   using the notations (notations : http://www.w3.org/TR/exi-primer/#exiBody)
       These notations are the things that are defined by "Grammar"
   - Next the notations in the grammar are given their binary equivalents
   - Finally the whole binary document is merged.  :-)


Note: There are also specific details as to how each data( values or content
)  has to be encoded in binary format
                (that is, how an integer is to be encoded, and so on...)


By the way, What are these "state" things?

   - As we start converting the XML file/stream, we traverse through the XML
   content sequentially.
   - At any given point of time we are at a particular( so called) "state"
   - The notations used in the grammar(
   http://www.w3.org/TR/exi-primer/#exiBody ) best shows what states might
   look like

For a simple example, consider,

> <classroom level="5"></classroom>
>
Here, as we start converting,

   1. first we encounter a start of a tag.  ( now we are at the state :
   "start of tag" )
        then we could expect to see its attributes
   2. we have an attribute "level" ( now we change state to "attribute" )
   3. then we have the attribute's value ("*Attribute*'s value" because we
   came to this state from the state of "attribute")

This can very well mapped to "Events" also.
That is,

   1. Event of "Occurrence of starting of a tag"
   2. Event of "Occurrence of an attribute"
   3. Event of "Occurence of an attribute's value"

I hope this is helpful as a good starter (although it lacks necessary
details)

I'll try to give more details as and when read through them ( and probably
understand them :-)

Regards,
Ashok Gowtham

Re: [Exip-develop] EXIP project

[Rumen K. <kju...@gm...>]

Hi Kailash,

You are right that EXI specification is quite extensive. However, the
easiest way to start with the project is to just have a basic idea about it
without delving into details. For example you can start implementing some of
the methods in the Stream I/O folder of the project. Let say you started
with decodeUnsignedInteger() -
/**
 * @brief Decode EXI Unsigned Integer type
 * Decode an arbitrary precision non negative integer using a sequence of
 * octets. The most significant bit of the last octet is set to zero to
 * indicate sequence termination. Only seven bits per octet are used to
 * store the integer's value.
 *
 * @param[in] strm EXI stream of bits
 * @param[out] int_val resulting unsigned integer value
 * @return Error handling code
 */
errorCode decodeUnsignedInteger(EXIStream* strm, unsigned int* int_val);

Then of course, as you also said, it is needed to check the EXI
specification for the Unsigned Integer EXI type -
http://www.w3.org/TR/exi/#encodingUnsignedInteger
In this way it is easier to grasp the specification too.

I am currently working on defining some specific tasks in the Trac tool -
https://sourceforge.net/apps/trac/exip/ - you can check there soon for some
tickets with details and description about available tasks. They will not
require good understanding of all the details about EXI.

When you start working on something please let the others know about it.
One sentence is enough, for example in a wiki page on
https://sourceforge.net/apps/trac/exip/wiki/DevelopersList.

Also, I would like to ask you to subscribe to exip-develop mailing list (
https://lists.sourceforge.net/lists/listinfo/exip-develop), if you haven't
done so, and post your questions there so that all of us know what is going
on and who is working on what.

Regards,
Rumen

On Wed, Jul 21, 2010 at 9:28 PM, Kailash Toshniwal <kai...@gm...>wrote:

> Hi Rumen,
> This project seems to be really good and big. I was looking at exi
> documentations,its really hard and huge too and I am not very familiar
> with even XML except for very basic so I was wondering how long will
> it take to learn EXI and start coding the library in C? Also please
> tell me if I can work on this project without delving much into exi? I
> mean reading about exi as and when needed for coding is alright but if
> the project demands to learn exi and xml concepts thoroughly before we
> can start then it may take lot of time and I am looking for a project
> where I can get coding started quickly (apart from planning time).
> Please let me know your thoughts and ideas if any.
>
> Thanks,
> Kailash

Re: [Exip-develop] EXIP project

[Rumen K. <kju...@gm...>]

Hi Yuh-Jia,

Thank you for your unit testing suggestions - I am looking at them.
I am also trying to define separate tasks but it is quite time consuming. I
am working on that in the Trac tool https://sourceforge.net/apps/trac/exip/ -
you can check there soon for some tickets with details and description about
available tasks. Meanwhile, in case you want to start writing code you can
begin with implementing some of the methods in the Stream I/O folder of the
project. The headers have quite extensive comments but if something is
unclear you can always ask me. When you start working on something please
let the others know about it. One sentence is enough, for example in a wiki
page on https://sourceforge.net/apps/trac/exip/wiki/DevelopersList.

Also, I would like to ask you to subscribe to exip-develop mailing list (
https://lists.sourceforge.net/lists/listinfo/exip-develop), if you haven't
done so, and post your questions there so that all of us know what is going
on and who is working on what.

Regards,
Rumen


On Wed, Jul 21, 2010 at 9:46 AM, Yuh-Jia Lim
<yu...@us...>wrote:

> Hi Rumen,
>
> Thanks for your email. I'm currently reading EXI primer and looking at
> other EXI projects' code to get up to speed with the specifications.
> With regard to unit testing, I've used CppUnit for C++. I've read good
> reviews about CUnit <https://sourceforge.net/projects/cunit/> and check<https://sourceforge.net/projects/check/>.
>
>
> I was wondering if you have any specific tasks that you have in mind for
> now, like writing unit tests, etc. I think having some defined tasks would
> really help to get things started - especially for newbies to open source
> development like myself.
>
> Thanks,
> Yuh-Jia
>

Re: [Exip-develop] EXIP project

[Rumen K. <kju...@gm...>]

On Tue, Jul 20, 2010 at 1:58 PM, <dh...@in...> wrote:

>
> For the record,
>
> is my subscription towards the sourceforge site totally free?
>
> I know that sourceforge accepts donations but are they all voluntary?
>

More info is available at
https://sourceforge.net/apps/trac/sourceforge/wiki/Donations
The EXIP project has not opt-in for donations. It is important to know how
the money will be invested in the project before accepting any donations.


>
> peace,
>
> dagmar
>
>

[Exip-develop] Fwd: EXIP project

[Rumen K. <kju...@gm...>]

---------- Forwarded message ----------
Hi digi,

Please find my answers to your questions below:


> Am i restricted to C, or could i use C++ ?


The main reason for choosing pure C was that the embedded platform I am
interested in does not provide C++ compiler. Also many other embedded
platforms are developed in C. Of course, if the project is successful
we might extend it with C++ version of it.


>
> I think the first step is creating software, that converts an XML towards
> EXI, and an EXI towards an XML. Such can be used as a library, and
> from there, needed bells and whistles and functionalities,
> can arouse.
>

I slightly disagree with you. If we are to go that way:  XML -> XML parser
-> XML Infoset API -> EXI serializer -> EXI stream
we need to include a XML parser in the project which I believe
is unnecessary. That is what EXIficient project did. What we need is just to
define something like SAX API which is event driven, simple
and describe the XML Infoset (http://www.w3.org/TR/xml-infoset/). This would
be the API that the applications will use to work with our EXI processor.

I am using an ordinary text editor (gedit) and gcc.
>
> I think this will fit in the CVS (SVN?) but we need to discuss,
> the boundaries of the application before releasing a new version.
>

We are using SVN for this project.


>
> peace,
>
> digi


I am sending this email to the exip-develop mailing list (
https://lists.sourceforge.net/lists/listinfo/exip-develop). Please subscribe
there and send your questions to it so that the others can read them too.

Regards,
Rumen

Re: [Exip-develop] EXIP project

[Rumen K. <kju...@gm...>]

Hi digi,

Please find my answers to your questions below:


> Am i restricted to C, or could i use C++ ?


The main reason for choosing pure C was that the embedded platform I am
interested in does not provide C++ compiler. Also many other embedded
platforms are developed in C. Of course, if the project is successful
we might extend it with C++ version of it.


>
> I think the first step is creating software, that converts an XML towards
> EXI, and an EXI towards an XML. Such can be used as a library, and
> from there, needed bells and whistles and functionalities,
> can arouse.
>

I slightly disagree with you. If we are to go that way:  XML -> XML parser
-> XML Infoset API -> EXI serializer -> EXI stream
we need to include a XML parser in the project which I believe
is unnecessary. That is what EXIficient project did. What we need is just to
define something like SAX API which is event driven, simple
and describe the XML Infoset (http://www.w3.org/TR/xml-infoset/). This would
be the API that the applications will use to work with our EXI processor.

I am using an ordinary text editor (gedit) and gcc.
>
> I think this will fit in the CVS (SVN?) but we need to discuss,
> the boundaries of the application before releasing a new version.
>

We are using SVN for this project.


>
> peace,
>
> digi


I am sending this email to the exip-develop mailing list (
https://lists.sourceforge.net/lists/listinfo/exip-develop). Please subscribe
there and send your questions to it so that the others can read them too.

Regards,
Rumen