publex-developers

[Publex-developers] [publex - Developers] database

[PubleX Developer's M. L. <pub...@li...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4118792
By: harnas83

Hi,

I'm thinking about the database layer of publex, and I have some questions..

First of all, the DB functionality. As far as I understand, the DB will store
the documents (so we need to be able to send those files to DB and get them
to clients) this functionality is simply implemented using Microsoft.Data.SqlXml
class.
Second thing is authentication and authorization. How will publex menage this
matter? Will it use some general authentication for each client instance (and
then the DB access will allow anonymous users) or there will be separate class
(and DB table) for manageing users acounts.
Version controling. We were talking about it on IRC chanel: 
cyqotiq: "various people use this program to work on a single Documentation
project, someone will need to be a document control person. This person will
need to know where any given document is at any given time". So my guess is
that publex will use some kind of copy-modify-merge model. User makes a copy
of project files to his local drive the DB registers which user is working on
which file (so the "document control person" knows what is going on) and previously
copyed files not saved back to DB are marked out-of-date.

I just started thinking about this, so if I'm completely wrong I would appreciate
your insights.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=645437

Re: [Publex-developers] [publex - Developers] database

[PubleX Developer's M. L. <pub...@li...>]

Actually, you just about hit the mark on everything.  The process can really
get detailed when you begin describing the precise activities for each
person in the documentation process.  But I've managed to narrow this down
to a necessary three positions.

Optionally, when PubleX is installed, it may be installed as a stand-alone
(single-user) module, which will use local anonymous DB access.  It may also
be installed in a group (multi-user) module, where it will require that a
server component be pre-installed on a remote machine (or possibly running
locally over a virtual machine or some type of VPN.  The details of how this
will work are still shady right now.  The idea is that PubleX may be used to
modify a documentation project on a single computer - DB is local - or over
a network with multiple clients - DB is managed on a server with write
access restricted to just that service.

All SQL input/output methods will need to be placed within
PubleX.Core.DB(in the PubleXCore project) as classes or interfaces
that may be exposed by
a server component (a seperate EXE project) or by a 'Virtual Server" for
stand-alone mode.  As far as PubleX itself is concerned, the DB requests
should all be the same, regardless of which model is being used.  The
protocol being used (local direct or remote TCP) will be set in the
configuration during installation, and will be modifyable during runtime by
the user.  This is to allow a single-user mode to be "switched" into a
client mode.

The three positions I mentioned are as follows:  Publication Control,
Project Mangement, and Project Editor.  It is possible for all three of
these to be the same person, but it's really not recommended.

Publication Control - This position is responsible for assigning tasks to
users, tracking the document locations and status, and gathering the files
to send on to another station.  This is where the DB interface for end-users
will be used.  I'll get into the stations a little later.

Project Management - This position is responsible for deciding guide lines
for documents, which documents go with which projects (or chapters), and
which documents are a higher priority than the others.

Project Editor - This is our primary end-user.  This person actually edits
the files.  There will be user levels within this group, but what those user
levels are and what they can do will be dependant on what the Project Manger
decides.  For example, with a technical manual, a certain chapter might be
designated as "expert" while another might be designated as 'general'.  A
level 1 user (lowest level) would only be allowed to work on general
documents, while a level 3 (highest level) would be allowed to work on any
documents.  Of course, there might be more than just 3 levels.  That depends
on what the Manger decides.

Stations are the various "check-points" of a document's life.  When the
project is first created, the Project Manger sets up all the technical
details (assigning documents to chapters, giving the priority for the
documents, and getting the basic database ready for use).  At this point,
the documents are put into play.  Editors may check them out.  Ideally, the
Project Control will be able to assign documents to different editors based
on which editors are available for editing and what the user levels for the
editors are compared to the status of the document.  The editor checks the
files out for editing, at which point the file is copied to their machine
into a local directory.  The database will then mark that file as being
"unavailable".

When the editor is finished, he will check the file back in, moving his
local data back to the server's repository.  The database is updated with
the new status of the documents and a snapshot of old data is made when the
old data is archived.  Once all of the edits have been made - this requires
several checking in and checking out of the files - and the document is
ready for delivery, the Publication Control station will gather all of the
documents that pertain to a delivery package - this might be a single
chapter, or an entire book.  This package is then sent out to whoever is
receiving the delivery.

Additional stations might be included within this process.  It would make
things much more difficult to track, but the more we can readily track with
the database, the better our program will be.  Configuration Management
members would then be used to communicate between various stations.
Configuration Management and Publication Control might be the same station.
This would probably only be used if there were a station for a Technical
Editor (someone to correct technical errors and grammar) and/or a Subject
Matter Expert to correct the subject matter and make "redline" changes for
outdated or incorrect data.

In order to fully support all of these stations, PubleX would need to
support displaying the XML documents as if it were a PDF or a print
preview.  Then provide tools for both technical editors and SME stations to
make corrections (annotations).  These corrections would be sent back to the
Publication Control with the document, and the Project Editor would update
the documents with these changes.

There are a lot of variables in all of this, and there is no way we could
provide an interface and tools for every possible station.  But if we can
meet the main three stations (Pubs Control for assigning editors their work,
Project Mangement for running administrative tasks on the project, and
Editors for editing the documents), then we will be fine.  Eventually, I
would like to also support handling an additional station for Configuration
Management, SME, and Technical Editor.  But that might very well be version
3 or 4. :)

>From this basic overview - and that's all this is... an overview - you can
probably get an idea of what the database would be used for.  If you have
any ideas or suggestions, I'm open to hear them.  If you have any questions,
let me know.

Jason

Re: [Publex-developers] [publex - Developers] database

[PubleX Developer's M. L. <pub...@li...>]

I've committed the changes to te new project XmlUIDev.  This project is the
first PubleX plugin.  It's a MenuPlugin object, so it can be accessed on the
"Tools" > "Addins" > "XML UI Designer" menu.

It's really rough right now, but it does work for the basic layout design of
windows with common controls.  It doesn't save anything out to XML yet, but
that will be the next step.  Right now, I'm trying to clean up the redrawing
of the controls and the update of properties.  When you update properties,
you have to either resize the control or switch windows to force the control
to update on screen.

Once I get the graphics work cleaned up a bit, I will work on exporting the
designed window to an XUI file and being able to load an XUI file into the
designer.  When this is working, then we'll have our XUI loader, and the
toolbar should work.  This is what's causing the message box you get when
you execute the program.

Jason

[Publex-developers] [publex - Developers] RE: database

[PubleX Developer's M. L. <pub...@li...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4121569
By: cyqotiq

I've already answered this question in the mailing list, but for the sake of
having the answer here in the future as well, I will re-post my answer.  This
was a very good set of questions, and the answers should be available for anyone
who needs this information in the future.

Actually, you just about hit the mark on everything.  The process can really
get detailed when you begin describing the precise activities for each person
in the documentation process.  But I've managed to narrow this down to a necessary
three positions.

Optionally, when PubleX is installed, it may be installed as a stand-alone
(single-user) module, which will use local anonymous DB access.  It may also
be installed in a group (multi-user) module, where it will require that a server
component be pre-installed on a remote machine (or possibly running locally
over a virtual machine or some type of VPN.  The details of how this will work
are still shady right now.  The idea is that PubleX may be used to modify a
documentation project on a single computer - DB is local - or over a network
with multiple clients - DB is managed on a server with write access restricted
to just that service.

All SQL input/output methods will need to be placed within PubleX.Core.DB (in
the PubleXCore project) as classes or interfaces that may be exposed by a server
component (a separate EXE project) or by a 'Virtual Server" for stand-alone
mode.  As far as PubleX itself is concerned, the DB requests should all be the
same, regardless of which model is being used.  The protocol being used (local
direct or remote TCP) will be set in the configuration during installation,
and will be modifiable during runtime by the user.  This is to allow a single-user
mode to be "switched" into a client mode.

The three positions I mentioned are as follows:  Publication Control, Project
Management, and Project Editor.  It is possible for all three of these to be
the same person, but it's really not recommended.

Publication Control - This position is responsible for assigning tasks to users,
tracking the document locations and status, and gathering the files to send
on to another station.  This is where the DB interface for end-users will be
used.  I'll get into the stations a little later.

Project Management - This position is responsible for deciding guide lines for
documents, which documents go with which projects (or chapters), and which documents
are a higher priority than the others.

Project Editor - This is our primary end-user.  This person actually edits the
files.  There will be user levels within this group, but what those user levels
are and what they can do will be dependent on what the Project Manger decides.
For example, with a technical manual, a certain chapter might be designated
as "expert" while another might be designated as 'general'.  A level 1 user
(lowest level) would only be allowed to work on general documents, while a level
3 (highest level) would be allowed to work on any documents.  Of course, there
might be more than just 3 levels.  That depends on what the Manger decides.

Stations are the various "check-points" of a document's life.  When the project
is first created, the Project Manger sets up all the technical details (assigning
documents to chapters, giving the priority for the documents, and getting the
basic database ready for use).  At this point, the documents are put into play.
Editors may check them out.  Ideally, the Project Control will be able to assign
documents to different editors based on which editors are available for editing
and what the user levels for the editors are compared to the status of the document.
The editor checks the files out for editing, at which point the file is copied
to their machine into a local directory.  The database will then mark that file
as being "unavailable".

When the editor is finished, he will check the file back in, moving his local
data back to the server's repository.  The database is updated with the new
status of the documents and a snapshot of old data is made when the old data
is archived.  Once all of the edits have been made - this requires several checking
in and checking out of the files - and the document is ready for delivery, the
Publication Control station will gather all of the documents that pertain to
a delivery package - this might be a single chapter, or an entire book.  This
package is then sent out to whoever is receiving the delivery.

Additional stations might be included within this process.  It would make things
much more difficult to track, but the more we can readily track with the database,
the better our program will be.  Configuration Management members would then
be used to communicate between various stations.  Configuration Management and
Publication Control might be the same station.  This would probably only be
used if there were a station for a Technical Editor (someone to correct technical
errors and grammar) and/or a Subject Matter Expert to correct the subject matter
and make "redline" changes for outdated or incorrect data.

In order to fully support all of these stations, PubleX would need to support
displaying the XML documents as if it were a PDF or a print preview.  Then provide
tools for both technical editors and SME stations to make corrections (annotations).
These corrections would be sent back to the Publication Control with the document,
and the Project Editor would update the documents with these changes.

There are a lot of variables in all of this, and there is no way we could provide
an interface and tools for every possible station.  But if we can meet the main
three stations (Pubs Control for assigning editors their work, Project Management
for running administrative tasks on the project, and Editors for editing the
documents), then we will be fine.  Eventually, I would like to also support
handling an additional station for Configuration Management, SME, and Technical
Editor.  But that might very well be version 3 or 4. :)

>From this basic overview - and that's all this is... an overview - you can probably
get an idea of what the database would be used for.  If you have any ideas or
suggestions, I'm open to hear them.  If you have any questions, let me know.

Jason

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=645437