OK, I wrote some network functions parsing the server response in it's current state.
The project files are uploded to the server. Use above link to download.

After first start the Category table will be empty. Use Articles|synchronize to download whole category tree from Decard's site.
Note: There is no error check. It will probably not work with firewals (not tested). If we changes the formar of the data server returns, this variant will stop working.

Any reports are highly appreciated, because we need test on different OS's and network configurations.

Regards.

To Pelaillo:

Hi, are you willing to add the same interface scripts to your http://fade.freeserverhost.net/ site as in Decard's "fade" - http://fade.decard.net ? (Of course the interface formats are not finished yet.)

This will make possible to use both servers for the offline browser.

Also, what is the state of your browser project. Actually I don't want to use IE engine or RichText (but will be forced to use one of them if there is no alternative.)

Regards.

Hi and my best wishes in this new year for all of you my friends

It would be nice to have only one common project to fit everyone needs. I started with the idea of having it so slender that neither a database is needed...

Regarding the browser, it depends on the features requested. The priority order to work on is this:

1.Fixed font rendering with paragraph alignment in body and table cells.
2.Table attributes: borders, bgcolors
3.Hyperlinks
4.Form controls: text boxes, combo boxes and buttons
5.png, jpg and gif rendering on body and table cells

I'll try to assign more time to the project and also to prepare terrain/coordination in order to get more help.

Hi, and happy new year for you too.




Well, database is not actually needed for the server side. Every "FADE" server can keep information in whatever format it wants. The main idea is to have one common interface for connection with the offline client - for example, if you support, getcat.php (or .cgi or .asp) that to return the same information like the Decard's variant (mentioned in above posts) the client will be able to read the category data from the server. (Also, the server have to keep some ID information that to connect articles with category and the author).
Of course this specification is not very clear yet, but it must be specified in order to make everything compatible - so, you can give any suggestions and opinions on this point.


Well, actually my idea was to implement only very base formating features in order to get more common look and feel of the articles. Full HTML format will be not usefull at all. I wanted to use some subset/superset of Wiki formating language, because it is clear enough and allows free reading of the text files even without any rendering (during write/edit).

So at first glance we need:
1. normal/bold/underline/italic fonts - proportional should be great, but monospaced is OK as well.
2. Bullet (and maybe numbered lists)
3. Tables - highly desired.
4. Images - desired but not actually too important.
5. Hiperlinks - to external URL and to internal articles.

Regards.

hi, johnfound, i don't know if this link is usefull?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_results_of_calling_example.asp

No, you missunderstood me. It is not a problem for FASM/Fresh to use CDECL. It is easy as you can see in the program draft mentioned above. It uses CDECL API of SQLite without problems.
The problem is (and it is mainly aesthetic ) it the CDECL procedures need fixing of the stack from the caller - it is one more instruction after every call to the API function with CDECL convention.

Regards.

You could just recompile SQLite with STDCALL calling convention? Not much of a big deal...

sorry for the misunderstanding, johnfound...

Well, actually it is a problem for me, because I have no any C compilers installed and I am not intended to install one.
Perhaps, for now it is better to use SQLite in its standard form and later, I have some intentions about our own FASM based SQL engine (maybe SQLite compatible). It definately will be smaller than SQLite, i.e. more suitable for asm projects.

Regards.

Why not you try Firebird?

Is it really so bad? Microsoft's VC++ 2003 is available for free, doesn't have a weird license like MASM does, has the full optimizer etc., and doesn't install a lot of weird stuff on your machine. After the initial install you can remove all the samples etc., and it won't take up too much space. Oh well, your choice

Is STDCALL really that much of an issue anyway? I know it's more aesthetically pleasing, but it's not like it matters too much. Of course I'm using it myself where I can, but I don't think it's anything to lose sleep over

Because of the size. Don't you think that 17kbytes (well, now) FTnT.exe mentioned above will not match good with several megabytes of Firebird RDBMS? (I like Firebird and InterBase. )



That is exactly my opinion too. If we begin to write our own RDBMS, that is another deal. But it is for the future...

Regards

Firebird embedded(fb_client.dll) is just 1.44MB(for me new to bare machine programming this is not too much). But wow...the "Lite" in SQLite really means what it means.

I added an option to submit and view articles (very simple by now).
try: code snippets/string functions/string length.

But I still don't have a precised idea how to store article authors... some idea?

John, can you explain to me what did you mean in your draft:

Articles
~~~~~~~~
ArticleID: integer ; this is the ID from the central database - the artile will be identified by this number.
EditionID: integer ; ID for article edition from the central database.
Category: integer ; category ID
Title: TEXT
Author: integer ; foreign key from Authors
Status: integer ; flags: valid, local, deleted, etc.
PDate: integer ; date/time of the creation.
Body: TEXT ; the text of the article. The format have to be disscussed.
Prev: integer ; points to the previous edition of the article.

I'm thinking about editionID and Prev fields... what do they actually mean? Can you explain this system of storing article editions?

I think the Prev field keeps track of the evolution of an article. If it is to do so, it's redundant, because you can use PDate to this task, and even easier.

For the authors, if you expect more than one for the same article, it's best to have another table AuthorArticle(AuthorID, ArticleID: integer) relating an author to an article. The Article table doesn't reference authors and vice-versa.

Yea, you are right, the one of both fields is redundant. Every of them can be removed without harm to the system.
If there is only Prev - it will form linked list to the previous editions of the article and ArticleID must be unique. If there is only EditionID - then, article ID will be one for all editions of the article and EditionID will differs between editions.
Well in both cases there is a question "How the SQL will select the last edition - in the case of EditionID it could be the edition with maximal EditionID number (hm, maybe PData can serve this purpose as well...)

In the case of Prev, maybe it worts to have reverse linked list with field "Next" instead of "Prev" that to contain the ArticleID of the next (newer) edition. Then the main select query will be: "select * from articles where Next is NULL". In this case the track of earlier editions will be more hard to be done while the SQL query can select only one edition back on every execution: "Select * from Articles where Next = ThisArticleID" will return the article edition that precede the given article edition.

Well to generalize:
1. "EditionID" (or Date based) approach provides easy selecting of whole "package" of article editions at once. Only determining of the last one needs sorting (slower).
2. The "Next" approach provides easy (and fast) select of the latest edition and hard and slow select of the previous editions.

About the authors: IMHO, what you think about simply removing the authors information, as a special tables and processing in the server. Then, if someone wants to sign its articles, he/she simply can add his/her name at the end of the text of the article...

About the "status" field - it is another field that is not very clear for me... what actually will store it. But IMHO, we need some flags information about the articles. For example, if the editors team decide to delete some article, the server have to mark this article as "deleted" and to signal the local clients about that. Even if the user decide to leave the article on its offline database, this article should not be sended to the server as "New" article on the update sessions.

BTW: What you think about the format of the articles? Actually I tend to think that RTF could be one good solution of this problem - WYSIWYG editing, embeded images, relatively light viewer/editor. There is no so many formats that can provide such functionality. The only problem I can see is that it will be harder to make on-line engine to convert from RTF to HTML...

Regards.

beppe85, I read your post just today - visibly you post it when I wrote my answer to decard. Anyway, I am agree about PDate field.
About the authors, as I wrote in my previous post, maybe it is not necessary to keep track of authors of the articles at all...

To all: I have following questions, that I couldn't find answers searching internet and messageboards:

Can I post binary data through POST method without encoding it to be pure ASCII? Concerning what I read, the POST is quite similar to GET with difference that I have to send something like:


I suppose I wrong somewhere...

Where I can find one simple example of POST request with explanations of the header fields? I tryed to read HTTP specification, but it is so common and I simply can't get the whole picture without reading tons of information.

Regards.

Hi all.

After exact check in my english-bulgarian dictionary, I think that we should stop using the name FADE, because of it's pretty negative meaning...
I am not against abbreviation (of course) but we must invent some more positive name for this project...

Any suggestions?

FADE doesn't necessarily have to be negative - rather than "fade out", it could be "fade in"... signifying that it will become more popular, even if slowly

What about:

1. ahead: assembly helping advocate

2. fresco: Fresh collaborative documentation

3. frisky (no abbreviation here, simply sound and meaningful name)