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