/[cvs]/nfo/perl/libs/OEF/doc/Why/Queue.pod
ViewVC logotype

Diff of /nfo/perl/libs/OEF/doc/Why/Queue.pod

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.3 by joko, Tue Jan 28 10:01:43 2003 UTC revision 1.4 by joko, Tue Jan 28 10:07:28 2003 UTC
# Line 3  package OEF::Why::Queue; Line 3  package OEF::Why::Queue;
3    
4  =pod  =pod
5    
6  - computing convenience from windows perspective/view[point]:    - computing convenience from windows perspective/view[point]:
7    - base level:      - base level:
8      - gnu -> cygwin        - gnu -> cygwin
9    - user-level:      - user-level:
10      - two hotsync-buttons:        - two hotsync-buttons:
11        - synchronize files with others:          - synchronize files with others:
12           RsyncHere|RsyncThere -> rsync -> cygwin -> SSH-client-library -> (SSH-daemon -> [cygwin] -> remote-filesystem)             RsyncHere|RsyncThere -> rsync -> cygwin -> SSH-client-library -> (SSH-daemon -> [cygwin] -> remote-filesystem)
13        - synchronize addresses with others:          - synchronize addresses with others:
14           Outlook -> OLE -> outlook2ldap -> Net::LDAP[S] -> (LDAP-daemon -> (LDAP-daemon-storage-impl.: dbm|proxy|mysql?) -> remote-filesystem)             Outlook -> OLE -> outlook2ldap -> Net::LDAP[S] -> (LDAP-daemon -> (LDAP-daemon-storage-impl.: dbm|proxy|mysql?) -> remote-filesystem)
15      - various "init"-scripts:        - various "init"-scripts:
16         - rsync: like the rsync.conf-preparation from ilo.de (it's a .bat)           - rsync: like the rsync.conf-preparation from ilo.de (it's a .bat)
17         - (vs.) other ssh-keygen-automation-scripts           - (vs.) other ssh-keygen-automation-scripts
18         - windows-settings (explorer, internet explorer)           - windows-settings (explorer, internet explorer)
19         - office (ms word, ms excel)           - office (ms word, ms excel)
20         - unattended.sourceforge.net           - unattended.sourceforge.net
21      - ideas (for the XyzHere-series)        - ideas (for the XyzHere-series)
22         - for the Internet Explorer: "mail/post link (including top-page) here" (to preconfigured|selected target)           - for the Internet Explorer: "mail/post link (including top-page) here" (to preconfigured|selected target)
23      
24      - use Tom or Pixie for live-object-passivation?
25        - the current attempt is going into the Tom-direction (Data::Storage::Handler::Tom, OEF::Component::Task)
26      
27      - have Data::Map load its mappings from (e.g.):
28        - a csv-file
29        - a ldap-dn
30      
31      - first components for an "OpenAccess":
32        - schema-editor (based on Tangram::Relational::Schema)
33        - relationship-/association-editor (based on Tangram::Relational::Schema)
34        - im-/export - metadata-editor (based on Data::Transfer::Sync)
35        - task-viewer for Tasks:
36          - deploy-/retreat schema
37          - run im-/export
38      
39      - integrate Torus (outlook2ldap) with Data::Transfer::Sync
40      
41      - fully persist native perl objects to be able to a) suspend processing, b) transfer the object to another process's scope (memory) and c) resume processing
42        - Data::Dumper? no, that's just for data
43        - Pixie? no, just Perl 5.8.0
44        - FreezeThaw - converting Perl structures to strings and back? hmm, seems to be for data only
45        - Storable?
46        - Memoize? no, just caches function return values (trade space for time)  ("Automatically cache results of functions")
47        - Attribute::Memoize? no, this is just an attribute-style interface to Memoize
48        - TOM?
49        - IPC::Cache - a perl module that implements an object storage space where data is persisted across process boundaries???
50           ... seems to be for data-persistence, also  ;(
51        - Aspect? hmmm, maybe .....
52      
53      - OQL on top of Tangram::QueryObject???
54      
55      - new perl modules:
56        Data::Filter
57        Regexp::Group
58        Getopt::Simple
59        Date::Merge
60      
61      - take care to declare your Plugin-modules as 'mixins' to BizWorks::Process
62      
63      - take care to specify BizWorks::Process-modules correctly
64        (including the full-name to the perl-namespace in the 'package'-declaration at the top of each file)
65      
66      
67      ~~~ 3
68      
69      - refactor use of class 'SystemEvent'
70        - maybe rename to show its scope already in classname (e.g. 'OefEvent')
71        - 1. generic inject on schema-level (like already successfully done with guid)
72        - auto-select of correct database at wiring-time (addLogDispatchHandler)
73      
74      - module-refactoring & namespace garbage collection:
75        + refactored mechanism to use sub-modules inside the BizWorks::Process-namespace (anchorless)
76        - refactor BizWorks::Process to be anchorless itself
77        - spread new loading-mechanism over already used scripts and integrate to API to be able to do some kind of ...
78           ... "remote component loading" (use in admin panel!)   ("admin panel"=admin-area/page/site/oberfläche/bereich? -- !)
79        - refactor parts of BizWorks to OEF? (OEF::Component, OEF::Process) again, think about looking at CPAN's PApp (more in detail!) here
80        - refactor files in etc/ to be compliant to some - not yet developed (tbd!) - kind of configuration-metabase-structure
81           ---> look at some already investigated modules from CPAN (Meta::XYZ???)
82        - refactor internal structure of files in doc/ to be html-renderable. use pod? (just with the new ones starting from 0.03)
83      
84      - use the session (backend->frontend) described below also to propagate error-messages from back- to frontend
85        --> each frontend uses one remote-/backend-session
86              ---> restricted access! (tbd)
87        --> each admin(-area) uses one remote-/backend-session
88              ---> full access!
89      
90      - document ids (identifiers) used:
91        - oid: object id (created by the innards of Tangram)
92        - guid: global id (created by a hook on object-insertion inside Tangram::Storage::_insert)
93        - serial: hash built from the content of the object (payload) via (e.g.) Digest::MD5 identifying it somehow...?
94        - sid: session id (created for _each_ object per session inside BizWorks::API::Session::_useobject ...
95                ... and also gets stored there (instead of the others in this list which come along with the object itself.)
96      
97      - about: global identifiers
98        - if you're designing a fully distributed (global) system it's important that your objects have assigned some kind
99          of "global identifier" (e.g. generated from Data::UUID or similar) when used across possibly disconnected systems.
100          --> each disconnection must/may/can be assumed as a "redeploy"
101               (an operation which invalidates e.g. all oids and/or breaks all relationships (or even more!))
102        - so relying on per-deployment identifiers (oids) from one of n systems will break your neck certainly   :-)
103        - how to implement this?
104          - implement & use session-based mechanisms! (compare ASP/php sessions)
105          - assure you have full session-based-communcation between _all_ layers ;-)  
106             .... else communication using identifiers will break at this very layer
107          - provide a guid -> <new-id-created-representing-the-master-guid>  -  mapping for each session
108          - integrate these new mechanisms as new layer between the backend and frontend
109            --> this will give you multiple frontends talking to the backend with their own identifiers! (and probably much more....)
110        - use this stuff to enhance infrastructure at system-setup/redeploy-/take-up/down-level:
111          - here we could apply (more or less) generic rules in the process-flow:
112            - flush session-metadata (guid->sid - mapping) ...
113            - ...
114        - this gives us
115          - possibility of having backend-db-redeploys transparent for the rest of the system
116          - possibility to drive "older" frontends (because we already have the mapping to the old identifiers) ....
117             ... just introduce a "VERSION" to actually measure age!
118      
119      - about: data
120        verbs:
121          pattern matching, filtering, scanning, searching, reading, writing, mungling, munging, transforming,
122          translating, migrating, finding, replacing, grep, stepping, viewing, reporting, including, feeding,
123          syncing, encapsulating, sending, transmitting, recieving, serializing, unserializing, mapping, meta, merging,
124          looking up, indexing, sharing, distributing, centralizing, backing up, restoring, comparing, diffing, matrix manipulation,
125          math manipulation, visualizing, filtering, iterating through, traversing, calculating, accumulating, freezing, processing,
126          routing, transferring, converting, loading, saving, storing, activating, archiving
127        nouns:
128          transitioning, set, structure, object, file, database, memory, filesystem
129        combined nouns:
130          --> combine the ones above
131        adjectives:
132          nested, flat, instantiated, raw, real, test, production,
133         ----> puzzle all by-random  ;-)
134      
135      - what's that?
136        - why Perl?
137          - hate writing too much code?
138        - why Tangram and Class::Tangram?
139          - hate writing sql?
140          - hate writing constructors?
141        - these are the most simple reasons from a RAD perspective,
142          (OEF) should give you much more, please read on... (and otherwhere)
143      
144      - PApp::Storable 2.04  -  ;-)  try to interconnect with Tangram 2.04.....
145      
146      - Data::Filter ...
147        - ... utilizing Regexp::Group
148      
149      - _don't_ start OEF!!!  try to use PApp!!!  (+POE, +P5EE)
150          ---> write components for these (and maybe try to tie them together in a convenient way)
151            ---> like already done with Data::Storage
152              ---> to _really_ start building higher level components for/with them (for real/bigger/distributed applications)
153                ---> "OpenDavid", "OpenAccess", "OpenExchange"
154      
155      - about: a database: (+rdbms, +odbms)
156        - basic actions (rdbms)
157          - holding
158          - storing and retrieving by identifier
159          - querying
160        - features (oo-style)
161          - orm (object relational mapper: maps oo-object-properties to table-fields)
162          - schema (maps oo-classes to oo-objects)
163          - relations
164          - constraints
165          - object inheritance
166        - highlevel services
167          - transactions
168          - stored procedures, views
169          - replication (master -> slave)
170      
171      - refactoring: use PerlIO::via to get _real_ layers (in this case for the "per-file basis")?
172      
173      ~~~ 2
174      
175      
176      
177      - refactor perl/libs/misc
178      
179      - refactor perl/libs/libp.pm into Data::Conversion:: and/or Data::
180      
181      ~~~ 1
182      
183      - Tangram::Storage/Data::UUID:
184        - rewrite _full_ functionality of Data::UUID to a pure perl version Data::UUID::PP or Data::UUID::PurePerl
185        + Data::UUID::PurePerl which uses Digest::MD5 with a random payload internally
186      
187      - OEF::Component::Transfer should get commands issued to
188        tell.pl transfer ....
189      
190      - documentation/self-documentation:
191        - doc/meta (for self-documenting purposes, place sloccounts and cvs-graphs/commitinfo/commitgraph) here
192        - doc/tracker (bug-, feature- and issue-tracking-system) - interface with cvs (file based use) somehow.....
193      
194      - cmd.pl/command.pl --> tell.pl
195      
196      - core-services to be abstracted out as components:
197        - lowlevel
198          - object manipulation (query, load, edit, save)
199          - data manipulation (transformation, conversion, encoding, encapsulation)
200          - communication services (rpc-xml, soap, file-system-based (pipe, socket, dir/file-poll/-watch), other rpc-mechs, net/raw (tcp, udp, ...))
201        - highlevel (utilizing above components and cross-utilizing themselves)
202          - reporting facility
203            - logging
204            - xyz
205          - processing facility (here is the actual code!)
206          - routing facility
207          (- view generation)
208      
209      - implement command-abstraction:
210        - use router/hop - mechanism
211        - declare commands in etc/BizWorks/Commands.pm, (or insert them to db and enhance router/hop-mechanism with "nodes") - map them to:
212           - description
213           - argument-container (hash containing passed-in arguments: this should be processed via some kinda "request"-object)
214        - at the end - a "response"-object should be the result of the command-routing process
215        - given this - it should be as easy to switch between synchronous/asynchronous-processing on command-level easily (speaking "on-the-fly")
216        - rewire this to a new script: cmd.pl/command.pl
217      
218      - add diff/merge on per-node-basis (inside!) for Data::Transfer::Sync as an alternative to md5-checksum-hashing
219      
220      - write small tool to scan source-code for various often-used-patterns:
221        - 1st run: TODO, HACK, REVIEW
222        - 2nd run: lowercase versions of above listed items
223        - report text/code after that (make context-width (before, after) configurable)
224      
225      - backend-sync: detect changes to underlying file when using DBD::CSV when syncing - will get destroyed otherwise ;)
226      
227      - central Data::UUID authority (two steps)
228        - move all code to a central location (BizWorks::Helper::UUID)
229        - central GUID-server/authority (like a ticket-authority) (RPC around BizWorks::Helper::UUID, etc.)
230      
231      - integrate a mechanism to disable new-guid-assignment when calling Tangram::Storage::_insert
232        - purpose: option for db_backup.pl dbkey=backend --action=restore
233      
234      - introduce generic "advanced.error.propagation"-mechanism for functions in Data::Storage::Handler to
235        let them return more verbose error-messages if any errors actually occour
236        - don't just return and don't pass back verbose strings in return values directly!
237          => pass back response-hash = {
238           errcode => 5,
239           errmsg => '<verbose error message>',
240           ok => 0,
241         }
242        - go oo via Event?
243        - go exception-style via try { ... } catch { ... }?
244      
245      - ideas to abstract the rotation-mechanism: (feed.pl --action=rotate)
246        - rotate.by.flag (is what we have now implemented in a hardwired fashion (backend_import.pl))
247        - rotate.by.date (give date to rotate by ....)
248      
249      - an abstract/third language to write validation processes in?
250        - intention: include this code (the identical) at _two_ system-nodes independent of used language (language-binding needed!) (python, javascript?)
251      
252      - libraries/modules: currency and/or datetime calculation for php and/or perl!?
253        - fields of "datetime": date, time, timezone
254        - fields of "currency": from -> to, setBase, getByCountry, (setBaseByCountry???)
255        - perl:
256          - Date::Manip
257        - php:
258          - PEAR/Date
259          - PEAR/Date/TimeZone???
260      
261      - frontend-sync - new concept:
262        - sync: two features - not more!
263          1. use guids for identification of nodes (wipe out usage of tangram-oid!!!: now the synchronization-layer is independent from tangram)
264          2. generic hook for im-/exports: wrap xml im-/export around that?
265        - maybe: don't do that above, but just _add_ the guid to the field-map of each node while syncing (generic "introduce"/"inject"-mechanism!)
266      
267      - OEF: docu: declared databases can be used similar to / compared to mountpoints known from e.g. the unix filesystem.
268        $process->{bizWorks}->{<database-key>}->storageMethod
269      
270      - OEF: look at pef@sourceforge!!!
271        - pef = perl enterprise framework
272        - contact authors!!!???
273      
274      - describe how to start write (new) code for/with OEF
275        - start with simple .pl-script
276        - encapsulate code inside the very same .pl-file into a special compartment to get it accessible from core OEF
277          - maybe provide an external tool to automatically do this job? (e.g. cat example.pl | oef.pl --refactor=script-compartment --outfile=example_c.pl)
278          - include to Config.pm!?
279        - move code to own process-namespace (e.g. "BizWorks")
280          - maybe provide an external tool to automatically do this job? (e.g. cat example.pl | oef.pl --refactor=process --outfile=BizWorks/)
281      
282      - attempt to start "OpenAccess" as a MS Access clone????? using...
283        - Data::
284        - OEF::
285        - Perl::Tk and/or mod_perl/Oak:: WebXyz::
286        - POE
287        - P5EE
288        - some more code......    ;-)
289      
290      - OEF::Scripting
291        - binding for scripting via perl/python/javascript/php? (even an emulated/open vbscript???)
292      
293      - OEF/FAQ.pod
294        - i can't find any getter/setter-methods in the source - where are they?
295        -> don't worry - they are there - but hidden away from Tangram / Class::Tangram - please read their documentation to get an insight into the mechanisms used in the layers using tangram for storage
296        - there are/will be some other "real"-getter/setter-methods or OEF will provide/wrap other class-generators as adapted/bridged handlers
297          e.g. Tie::SecureHash, Class::Contract, Class::Xyz, .....  (try to integrate/move utilization of Class::Tangram into this (new) layer as well....)
298      
299      - introduce mechanism to provide something like a "dynamic reversed mixin-inheritance"
300        (from the view of perl's mixin-module available from CPAN)
301        - purpose:
302          - don't mixin plugin-subobject's to a common concrete parent-container-objects, but ....
303          - .... dynamically (via eval) mixin an abstract parent-container-object into an arbitrary instantiated plugin-object's namespace
304          - this (maybe) will get you shared resources between applications and plugins but namespace-seperated methods on plugin-level, but ....
305          - .... still lets you have common methods available to all plugins declared in the abstract parent-container-object
306             (needed e.g. for 'load/unload' itself....)
307          => hierarchical plugin namespace at runtime - sharing resources, common methods and (maybe) other preconfigured (helper-)objects
308          - another idea/enhancement on top of this: dynamically mixin arbitrary/given package into _current_ __PACKAGE__
309          - another idea/enhancement parallel to this (maybe better/easier to use/implement/merge-with-POE?):
310             - provide each plugin with a meta-data-storage-container (kinda _SESSION/_STACK) which can/will get flushed on destroy, but ...
311                ... can also be made persistent on demand/request, or ...
312                ... sent to a remote location: would process-migration be possible with this???
313                   _start_proc(local)
314                   _pause_proc(local)
315                   _migrate_proc(local, remote)
316                     _migrate_proc_meta(local, remote)
317                     _migrate_proc_stack(local, remote)
318                   _resume_proc(remote)
319                   while (status = _query_proc(remote)) {
320                     print status
321                     last if status.ready
322                     last if status.error
323                   }
324      
325      - write code for (automatic )documentation-purposes:
326         - perl-filter to (hard) dump all _values_ sub- input- and output- variables
327         - perl-filter to (hard) extract sub-name and attributes
328         - perl-filter to (guess) all _names_ of a) passed-in (request)-variables (arguments, options) and b) passed-back (response-)variables ((processing-)results, boolesch or arbitraryly encoded status)
329         - perl-filter to (hard) extract additional in-/out-metadata ... how? already proposed somewhere - search linkdb
330      
331      - guid should be generated in a core module in the Data::-namespace to be accessible by both Data::Transfer::Sync and BizWorks::xyz
332        -> mkGuid
333        -> Data::Storage::Sync - metadata: add ->{isGuidProvider}???
334      
335      - Data::Transform::Deep:
336        - rename 'expand' to 'deep_expand'
337        - create new sub 'merge' (from 'hash2object_traverse_mixin'), use from 'hash2object'
338           - use IterArray and/or IterHash???
339      
340      - include main namespace (BizWorks, BizWorks::Process) in Config.pm somehow
341        ----> refactor code to provide declarative boot/startup
342         => SYNOPSIS:
343           my $app = OEF::Application->new(
344             config => $config,
345             namespaces => {
346               'BizWorks' => {
347             },
348             databases => [qw()],
349             packages => [qw()],
350           );
351           my $app = OEF::Application->new(package => 'BizWorks');
352           my $app = OEF::Application->new(script => 'feed.pl');
353      
354           $app->boot();
355           $app->run();
356      
357           propagation of config / further boot is done _after_ parsing the configuration
358           e.g. booting BizWorks is just declard in there - it will not happen "by default" any more
359             => the door maybe is open now to load plugins from/to other namespaces/scopes besides BizWorks
360      
361      - generic "makeSerial"-function (BizWorks::Process::Common) to make serials from some concrete objects
362        - rule: capitalize first letter of object-/class-name - append digest of object-payload (patched Data::Dumper)
363      
364      - patch Data::Dumper to respect e.g. Set::Object
365      
366      - synchronization: don't delete all nodes when running "export": just delete touched ones and show this via print "r" if $self->{verbose}
367      
368      - transparently send tangram-objects via RPC::XML???
369      
370      - introduce TTL and manual-purge-mechanism for HttpProxy
371      
372      - introduce OEF, OEF::Process in nfo/  (Open Enterprise Framework)
373        - the OEF-namespace:
374          - OEF::Process (BizWorks::Process)
375          - OEF::Script (xyz.pl, BizWorks::RunMe)
376          - OEF::Core (BizWorks, BizWorks::Boot)
377          - OEF::Request and OEF::Response? asynchronous?
378          - OEF::Application (BizWorks)
379          - OEF::Engine?
380        - DOEPF? (Distributed Open Enterprise Perl Framework)? hmmm... no what about PHP? Python?
381      
382      - what about code in BizWorks::Process::Core??? maybe use Data::Storage::Handler::Tangram::sendQuery
383      
384      - introduce mechanism for developer-machines to detect and propagate schema-changes to e.g. frontend-databases (configure this option/feature in Config.pm)
385    
386  - use Tom or Pixie for live-object-passivation?  $Id$
   - the current attempt is going into the Tom-direction (Data::Storage::Handler::Tom, OEF::Component::Task)  
   
 - have Data::Map load its mappings from (e.g.):  
   - a csv-file  
   - a ldap-dn  
   
 - first components for an "OpenAccess":  
   - schema-editor (based on Tangram::Relational::Schema)  
   - relationship-/association-editor (based on Tangram::Relational::Schema)  
   - im-/export - metadata-editor (based on Data::Transfer::Sync)  
   - task-viewer for Tasks:  
     - deploy-/retreat schema  
     - run im-/export  
   
 - integrate Torus (outlook2ldap) with Data::Transfer::Sync  
   
 - fully persist native perl objects to be able to a) suspend processing, b) transfer the object to another process's scope (memory) and c) resume processing  
   - Data::Dumper? no, that's just for data  
   - Pixie? no, just Perl 5.8.0  
   - FreezeThaw - converting Perl structures to strings and back? hmm, seems to be for data only  
   - Storable?  
   - Memoize? no, just caches function return values (trade space for time)  ("Automatically cache results of functions")  
   - Attribute::Memoize? no, this is just an attribute-style interface to Memoize  
   - TOM?  
   - IPC::Cache - a perl module that implements an object storage space where data is persisted across process boundaries???  
      ... seems to be for data-persistence, also  ;(  
   - Aspect? hmmm, maybe .....  
   
 - OQL on top of Tangram::QueryObject???  
   
 - new perl modules:  
   Data::Filter  
   Regexp::Group  
   Getopt::Simple  
   Date::Merge  
   
 - take care to declare your Plugin-modules as 'mixins' to BizWorks::Process  
   
 - take care to specify BizWorks::Process-modules correctly  
   (including the full-name to the perl-namespace in the 'package'-declaration at the top of each file)  
   
   
 ~~~ 3  
   
 - refactor use of class 'SystemEvent'  
   - maybe rename to show its scope already in classname (e.g. 'OefEvent')  
   - 1. generic inject on schema-level (like already successfully done with guid)  
   - auto-select of correct database at wiring-time (addLogDispatchHandler)  
   
 - module-refactoring & namespace garbage collection:  
   + refactored mechanism to use sub-modules inside the BizWorks::Process-namespace (anchorless)  
   - refactor BizWorks::Process to be anchorless itself  
   - spread new loading-mechanism over already used scripts and integrate to API to be able to do some kind of ...  
      ... "remote component loading" (use in admin panel!)   ("admin panel"=admin-area/page/site/oberfläche/bereich? -- !)  
   - refactor parts of BizWorks to OEF? (OEF::Component, OEF::Process) again, think about looking at CPAN's PApp (more in detail!) here  
   - refactor files in etc/ to be compliant to some - not yet developed (tbd!) - kind of configuration-metabase-structure  
      ---> look at some already investigated modules from CPAN (Meta::XYZ???)  
   - refactor internal structure of files in doc/ to be html-renderable. use pod? (just with the new ones starting from 0.03)  
   
 - use the session (backend->frontend) described below also to propagate error-messages from back- to frontend  
   --> each frontend uses one remote-/backend-session  
         ---> restricted access! (tbd)  
   --> each admin(-area) uses one remote-/backend-session  
         ---> full access!  
   
 - document ids (identifiers) used:  
   - oid: object id (created by the innards of Tangram)  
   - guid: global id (created by a hook on object-insertion inside Tangram::Storage::_insert)  
   - serial: hash built from the content of the object (payload) via (e.g.) Digest::MD5 identifying it somehow...?  
   - sid: session id (created for _each_ object per session inside BizWorks::API::Session::_useobject ...  
           ... and also gets stored there (instead of the others in this list which come along with the object itself.)  
   
 - about: global identifiers  
   - if you're designing a fully distributed (global) system it's important that your objects have assigned some kind  
     of "global identifier" (e.g. generated from Data::UUID or similar) when used across possibly disconnected systems.  
     --> each disconnection must/may/can be assumed as a "redeploy"  
          (an operation which invalidates e.g. all oids and/or breaks all relationships (or even more!))  
   - so relying on per-deployment identifiers (oids) from one of n systems will break your neck certainly   :-)  
   - how to implement this?  
     - implement & use session-based mechanisms! (compare ASP/php sessions)  
     - assure you have full session-based-communcation between _all_ layers ;-)    
        .... else communication using identifiers will break at this very layer  
     - provide a guid -> <new-id-created-representing-the-master-guid>  -  mapping for each session  
     - integrate these new mechanisms as new layer between the backend and frontend  
       --> this will give you multiple frontends talking to the backend with their own identifiers! (and probably much more....)  
   - use this stuff to enhance infrastructure at system-setup/redeploy-/take-up/down-level:  
     - here we could apply (more or less) generic rules in the process-flow:  
       - flush session-metadata (guid->sid - mapping) ...  
       - ...  
   - this gives us  
     - possibility of having backend-db-redeploys transparent for the rest of the system  
     - possibility to drive "older" frontends (because we already have the mapping to the old identifiers) ....  
        ... just introduce a "VERSION" to actually measure age!  
   
 - about: data  
   verbs:  
     pattern matching, filtering, scanning, searching, reading, writing, mungling, munging, transforming,  
     translating, migrating, finding, replacing, grep, stepping, viewing, reporting, including, feeding,  
     syncing, encapsulating, sending, transmitting, recieving, serializing, unserializing, mapping, meta, merging,  
     looking up, indexing, sharing, distributing, centralizing, backing up, restoring, comparing, diffing, matrix manipulation,  
     math manipulation, visualizing, filtering, iterating through, traversing, calculating, accumulating, freezing, processing,  
     routing, transferring, converting, loading, saving, storing, activating, archiving  
   nouns:  
     transitioning, set, structure, object, file, database, memory, filesystem  
   combined nouns:  
     --> combine the ones above  
   adjectives:  
     nested, flat, instantiated, raw, real, test, production,  
    ----> puzzle all by-random  ;-)  
   
 - what's that?  
   - why Perl?  
     - hate writing too much code?  
   - why Tangram and Class::Tangram?  
     - hate writing sql?  
     - hate writing constructors?  
   - these are the most simple reasons from a RAD perspective,  
     (OEF) should give you much more, please read on... (and otherwhere)  
   
 - PApp::Storable 2.04  -  ;-)  try to interconnect with Tangram 2.04.....  
   
 - Data::Filter ...  
   - ... utilizing Regexp::Group  
   
 - _don't_ start OEF!!!  try to use PApp!!!  (+POE, +P5EE)  
     ---> write components for these (and maybe try to tie them together in a convenient way)  
       ---> like already done with Data::Storage  
         ---> to _really_ start building higher level components for/with them (for real/bigger/distributed applications)  
           ---> "OpenDavid", "OpenAccess", "OpenExchange"  
   
 - about: a database: (+rdbms, +odbms)  
   - basic actions (rdbms)  
     - holding  
     - storing and retrieving by identifier  
     - querying  
   - features (oo-style)  
     - orm (object relational mapper: maps oo-object-properties to table-fields)  
     - schema (maps oo-classes to oo-objects)  
     - relations  
     - constraints  
     - object inheritance  
   - highlevel services  
     - transactions  
     - stored procedures, views  
     - replication (master -> slave)  
   
 - refactoring: use PerlIO::via to get _real_ layers (in this case for the "per-file basis")?  
   
 ~~~ 2  
   
   
   
 - refactor perl/libs/misc  
   
 - refactor perl/libs/libp.pm into Data::Conversion:: and/or Data::  
   
 ~~~ 1  
   
 - Tangram::Storage/Data::UUID:  
   - rewrite _full_ functionality of Data::UUID to a pure perl version Data::UUID::PP or Data::UUID::PurePerl  
   + Data::UUID::PurePerl which uses Digest::MD5 with a random payload internally  
   
 - OEF::Component::Transfer should get commands issued to  
   tell.pl transfer ....  
   
 - documentation/self-documentation:  
   - doc/meta (for self-documenting purposes, place sloccounts and cvs-graphs/commitinfo/commitgraph) here  
   - doc/tracker (bug-, feature- and issue-tracking-system) - interface with cvs (file based use) somehow.....  
   
 - cmd.pl/command.pl --> tell.pl  
   
 - core-services to be abstracted out as components:  
   - lowlevel  
     - object manipulation (query, load, edit, save)  
     - data manipulation (transformation, conversion, encoding, encapsulation)  
     - communication services (rpc-xml, soap, file-system-based (pipe, socket, dir/file-poll/-watch), other rpc-mechs, net/raw (tcp, udp, ...))  
   - highlevel (utilizing above components and cross-utilizing themselves)  
     - reporting facility  
       - logging  
       - xyz  
     - processing facility (here is the actual code!)  
     - routing facility  
     (- view generation)  
   
 - implement command-abstraction:  
   - use router/hop - mechanism  
   - declare commands in etc/BizWorks/Commands.pm, (or insert them to db and enhance router/hop-mechanism with "nodes") - map them to:  
      - description  
      - argument-container (hash containing passed-in arguments: this should be processed via some kinda "request"-object)  
   - at the end - a "response"-object should be the result of the command-routing process  
   - given this - it should be as easy to switch between synchronous/asynchronous-processing on command-level easily (speaking "on-the-fly")  
   - rewire this to a new script: cmd.pl/command.pl  
   
 - add diff/merge on per-node-basis (inside!) for Data::Transfer::Sync as an alternative to md5-checksum-hashing  
   
 - write small tool to scan source-code for various often-used-patterns:  
   - 1st run: TODO, HACK, REVIEW  
   - 2nd run: lowercase versions of above listed items  
   - report text/code after that (make context-width (before, after) configurable)  
   
 - backend-sync: detect changes to underlying file when using DBD::CSV when syncing - will get destroyed otherwise ;)  
   
 - central Data::UUID authority (two steps)  
   - move all code to a central location (BizWorks::Helper::UUID)  
   - central GUID-server/authority (like a ticket-authority) (RPC around BizWorks::Helper::UUID, etc.)  
   
 - integrate a mechanism to disable new-guid-assignment when calling Tangram::Storage::_insert  
   - purpose: option for db_backup.pl dbkey=backend --action=restore  
   
 - introduce generic "advanced.error.propagation"-mechanism for functions in Data::Storage::Handler to  
   let them return more verbose error-messages if any errors actually occour  
   - don't just return and don't pass back verbose strings in return values directly!  
     => pass back response-hash = {  
      errcode => 5,  
      errmsg => '<verbose error message>',  
      ok => 0,  
    }  
   - go oo via Event?  
   - go exception-style via try { ... } catch { ... }?  
   
 - ideas to abstract the rotation-mechanism: (feed.pl --action=rotate)  
   - rotate.by.flag (is what we have now implemented in a hardwired fashion (backend_import.pl))  
   - rotate.by.date (give date to rotate by ....)  
   
 - an abstract/third language to write validation processes in?  
   - intention: include this code (the identical) at _two_ system-nodes independent of used language (language-binding needed!) (python, javascript?)  
   
 - libraries/modules: currency and/or datetime calculation for php and/or perl!?  
   - fields of "datetime": date, time, timezone  
   - fields of "currency": from -> to, setBase, getByCountry, (setBaseByCountry???)  
   - perl:  
     - Date::Manip  
   - php:  
     - PEAR/Date  
     - PEAR/Date/TimeZone???  
   
 - frontend-sync - new concept:  
   - sync: two features - not more!  
     1. use guids for identification of nodes (wipe out usage of tangram-oid!!!: now the synchronization-layer is independent from tangram)  
     2. generic hook for im-/exports: wrap xml im-/export around that?  
   - maybe: don't do that above, but just _add_ the guid to the field-map of each node while syncing (generic "introduce"/"inject"-mechanism!)  
   
 - OEF: docu: declared databases can be used similar to / compared to mountpoints known from e.g. the unix filesystem.  
   $process->{bizWorks}->{<database-key>}->storageMethod  
   
 - OEF: look at pef@sourceforge!!!  
   - pef = perl enterprise framework  
   - contact authors!!!???  
   
 - describe how to start write (new) code for/with OEF  
   - start with simple .pl-script  
   - encapsulate code inside the very same .pl-file into a special compartment to get it accessible from core OEF  
     - maybe provide an external tool to automatically do this job? (e.g. cat example.pl | oef.pl --refactor=script-compartment --outfile=example_c.pl)  
     - include to Config.pm!?  
   - move code to own process-namespace (e.g. "BizWorks")  
     - maybe provide an external tool to automatically do this job? (e.g. cat example.pl | oef.pl --refactor=process --outfile=BizWorks/)  
   
 - attempt to start "OpenAccess" as a MS Access clone????? using...  
   - Data::  
   - OEF::  
   - Perl::Tk and/or mod_perl/Oak:: WebXyz::  
   - POE  
   - P5EE  
   - some more code......    ;-)  
   
 - OEF::Scripting  
   - binding for scripting via perl/python/javascript/php? (even an emulated/open vbscript???)  
   
 - OEF/FAQ.pod  
   - i can't find any getter/setter-methods in the source - where are they?  
   -> don't worry - they are there - but hidden away from Tangram / Class::Tangram - please read their documentation to get an insight into the mechanisms used in the layers using tangram for storage  
   - there are/will be some other "real"-getter/setter-methods or OEF will provide/wrap other class-generators as adapted/bridged handlers  
     e.g. Tie::SecureHash, Class::Contract, Class::Xyz, .....  (try to integrate/move utilization of Class::Tangram into this (new) layer as well....)  
   
 - introduce mechanism to provide something like a "dynamic reversed mixin-inheritance"  
   (from the view of perl's mixin-module available from CPAN)  
   - purpose:  
     - don't mixin plugin-subobject's to a common concrete parent-container-objects, but ....  
     - .... dynamically (via eval) mixin an abstract parent-container-object into an arbitrary instantiated plugin-object's namespace  
     - this (maybe) will get you shared resources between applications and plugins but namespace-seperated methods on plugin-level, but ....  
     - .... still lets you have common methods available to all plugins declared in the abstract parent-container-object  
        (needed e.g. for 'load/unload' itself....)  
     => hierarchical plugin namespace at runtime - sharing resources, common methods and (maybe) other preconfigured (helper-)objects  
     - another idea/enhancement on top of this: dynamically mixin arbitrary/given package into _current_ __PACKAGE__  
     - another idea/enhancement parallel to this (maybe better/easier to use/implement/merge-with-POE?):  
        - provide each plugin with a meta-data-storage-container (kinda _SESSION/_STACK) which can/will get flushed on destroy, but ...  
           ... can also be made persistent on demand/request, or ...  
           ... sent to a remote location: would process-migration be possible with this???  
              _start_proc(local)  
              _pause_proc(local)  
              _migrate_proc(local, remote)  
                _migrate_proc_meta(local, remote)  
                _migrate_proc_stack(local, remote)  
              _resume_proc(remote)  
              while (status = _query_proc(remote)) {  
                print status  
                last if status.ready  
                last if status.error  
              }  
   
 - write code for (automatic )documentation-purposes:  
    - perl-filter to (hard) dump all _values_ sub- input- and output- variables  
    - perl-filter to (hard) extract sub-name and attributes  
    - perl-filter to (guess) all _names_ of a) passed-in (request)-variables (arguments, options) and b) passed-back (response-)variables ((processing-)results, boolesch or arbitraryly encoded status)  
    - perl-filter to (hard) extract additional in-/out-metadata ... how? already proposed somewhere - search linkdb  
   
 - guid should be generated in a core module in the Data::-namespace to be accessible by both Data::Transfer::Sync and BizWorks::xyz  
   -> mkGuid  
   -> Data::Storage::Sync - metadata: add ->{isGuidProvider}???  
   
 - Data::Transform::Deep:  
   - rename 'expand' to 'deep_expand'  
   - create new sub 'merge' (from 'hash2object_traverse_mixin'), use from 'hash2object'  
      - use IterArray and/or IterHash???  
   
 - include main namespace (BizWorks, BizWorks::Process) in Config.pm somehow  
   ----> refactor code to provide declarative boot/startup  
    => SYNOPSIS:  
      my $app = OEF::Application->new(  
        config => $config,  
        namespaces => {  
          'BizWorks' => {  
        },  
        databases => [qw()],  
        packages => [qw()],  
      );  
      my $app = OEF::Application->new(package => 'BizWorks');  
      my $app = OEF::Application->new(script => 'feed.pl');  
   
      $app->boot();  
      $app->run();  
   
      propagation of config / further boot is done _after_ parsing the configuration  
      e.g. booting BizWorks is just declard in there - it will not happen "by default" any more  
        => the door maybe is open now to load plugins from/to other namespaces/scopes besides BizWorks  
   
 - generic "makeSerial"-function (BizWorks::Process::Common) to make serials from some concrete objects  
   - rule: capitalize first letter of object-/class-name - append digest of object-payload (patched Data::Dumper)  
   
 - patch Data::Dumper to respect e.g. Set::Object  
   
 - synchronization: don't delete all nodes when running "export": just delete touched ones and show this via print "r" if $self->{verbose}  
   
 - transparently send tangram-objects via RPC::XML???  
   
 - introduce TTL and manual-purge-mechanism for HttpProxy  
   
 - introduce OEF, OEF::Process in nfo/  (Open Enterprise Framework)  
   - the OEF-namespace:  
     - OEF::Process (BizWorks::Process)  
     - OEF::Script (xyz.pl, BizWorks::RunMe)  
     - OEF::Core (BizWorks, BizWorks::Boot)  
     - OEF::Request and OEF::Response? asynchronous?  
     - OEF::Application (BizWorks)  
     - OEF::Engine?  
   - DOEPF? (Distributed Open Enterprise Perl Framework)? hmmm... no what about PHP? Python?  
   
 - what about code in BizWorks::Process::Core??? maybe use Data::Storage::Handler::Tangram::sendQuery  
   
 - introduce mechanism for developer-machines to detect and propagate schema-changes to e.g. frontend-databases (configure this option/feature in Config.pm)  
387    
388  =cut  =cut
389    
390  1;  1;
391  __END__  __END__
   
 $Id$  
Legend:
Removed from v.1.3  
changed lines
  Added in v.1.4
MailToCvsAdmin">MailToCvsAdmin
 ViewVC Help
Powered by ViewVC 1.1.26 RSS 2.0 feed